After the mapper leaves: from making maps to leaving capability behind

For a long time I thought the obvious measure of a GIS project was the thing it produced. A map was finished, a map book was printed, a database was delivered and a set of layers worked. Outputs are comforting because they can be counted, photographed and put into reports. Māori GIS work gradually taught me to ask a much less comfortable question: what happens after the mapper leaves?

That question changed almost everything. A map can be excellent and still leave the people who need it dependent on the person who made it. A GIS can be technically sophisticated and still become useless when the one person who understands the folders moves on. A training event can be inspiring and still achieve almost nothing if the participant returns home and cannot reproduce what they saw. The real test of capability is not whether the system works while the expert is standing beside it. It is whether the work can continue afterwards, under the authority of the people who need it and in a form that can be carried forward.

Over time I came to see that this was more than a sustainability problem in the usual project-management sense. In Māori settings there was often an intergenerational dimension to the work. Whenua, place names, histories and community information were not temporary project assets. People might be using them for a Treaty claim today, environmental planning tomorrow and something quite different in ten or twenty years. The question was therefore not only whether the system survived the funding period, but whether knowledge, context and authority could survive changes in staff, software and organisations.

I am not Māori and do not claim a Māori worldview as my own. What I can describe is what working alongside Māori practitioners and communities taught me about capability. The strongest projects were not simply those that delivered technology. They were the ones that increased rangatiratanga over the work, reduced avoidable dependence and left people better able to make their own decisions about their information.

The finished map

My early claimant mapping work was naturally focused on production. There were historical plans to find, blocks to reconstruct, place names to correct, maps to prepare for researchers and claimants and hearing deadlines that were not especially interested in philosophical discussions about sustainable capability. Sometimes the immediate requirement really was simple: get the map finished and get it to the people who needed it.

That work mattered. Good maps made complicated evidence easier to understand. Historical plans could be compared with modern cadastre. Public Works takings, Crown purchases, waterways, roads and current property boundaries could be seen together. A large-format map or map book could make the geography of a claim visible in a way that pages of text could not.

The limitation was that a finished map was still a finished product. The moment somebody wanted to add another place, correct a name, change a boundary, include new research or produce a different scale, the product became the beginning of another dependency. Someone had to know how to make the change.

That was increasingly obvious by the mid-2000s. Communities were not simply asking for another printed map. Some wanted ongoing GIS capability so they could work with their own information, update it and use it for more than one project. The significant shift was from receiving a service to holding more of the capability themselves.

This is where a Māori framing changed the way I understood the problem. If information about whenua and community remained locked inside an external specialist's system, then technical access had improved but local authority had not necessarily improved with it. A beautifully produced map could still leave the community dependent on somebody outside the community every time it needed to be changed. The issue was not only access to technology. It was who could exercise meaningful control over the work.

The marae office

The Ngāti Manawa GIS pilot was one of the projects that pushed this question into the foreground for me. The idea was not merely to prepare another collection of maps. It considered what it would take to leave practical GIS capability with the group, including equipment, software, data, metadata, training and some structure around who could use and maintain the information.

The phrase I often use for this period is “put the GIS in the marae office”. It captures the change in direction. Instead of assuming the GIS belonged in the specialist's workplace and maps would travel outward from there, the objective became to move more of the capability closer to the people who needed it.

That sounds like a hardware decision, but it was more important than that. Putting the computer in the right building did not automatically create rangatiratanga over the information. People also needed access, skills, confidence, passwords, documentation and enough organisational support for the system to remain useful. The computer was part of the capability, not the capability itself.

The project also highlighted something that later became much clearer to me: a GIS is carried by relationships as much as by technology. People need to know who can help, who understands the data, who has authority to decide what is public and who will take responsibility when something changes. That relational side of capability sits closer to whanaungatanga than to the usual technology model of users, administrators and owners. The system survives because people are connected to one another around the work, not because a diagram says the platform is sustainable.

From access to rangatiratanga

A useful distinction emerged over time between access and control. Giving somebody access to a map is not the same as giving them the ability to maintain it. Giving a community a login to an external platform is not the same as ensuring it can move its information elsewhere. Providing training is not the same as building enough local confidence for people to question the trainer, the vendor or the government dataset.

The stronger objective was greater rangatiratanga over the work: the ability to make decisions about what is mapped, how it is held, who sees it and what happens next. I use that term carefully because rangatiratanga is much larger than GIS and not something a technical project can deliver. But within the narrow field of spatial information, the principle is useful. Capability should increase the ability of iwi and hapū to make decisions for themselves rather than replacing one dependency with another.

This also changed how I thought about technical design. Exportability mattered because people should be able to take their information elsewhere. Open formats mattered because they reduced lock-in. Multiple people knowing the system mattered because knowledge should not sit with one individual. Documentation mattered because the next person should not have to reconstruct the system from scratch. These are ordinary technical practices, but in this context they supported something larger than efficiency.

Ten DVDs

Around the same time we were developing what became known as ArcFlax and other claimant resource packages. These were attempts to make sophisticated GIS information usable by people who did not have full professional GIS environments. ArcReader could provide access to prepared maps and layers without requiring everyone to own the full ArcGIS desktop product. Resource packages could include imagery, PDFs, GIS layers, two-dimensional and three-dimensional views and other supporting information.

At one point the full distribution occupied ten DVDs, which was ambitious, useful and slightly absurd in equal measure. This was the period in which digital transformation still arrived in a cardboard box. The idea was genuinely important because people could explore information rather than merely receive one static map, and thousands of discs could put mapping resources in the hands of claimants and researchers who would otherwise have needed access to specialist systems.

But the technology exposed the difference between access and capability. A person could possess all ten DVDs and still not know how to update a layer. The viewer made information more accessible without necessarily making the recipient independent. The discs also depended on operating systems, file paths, software components and hardware that would eventually change.

The modern equivalent is not necessarily better. We have replaced the box of DVDs with web services, cloud platforms and identity systems. The physical media problem has almost disappeared, but new dependencies have taken its place. A service changes authentication, an account belongs to the wrong person, a subscription expires or a platform changes its licensing. The system still has dependencies. They have simply become less visible.

The deeper question is the same: can the people whose work depends on the system continue without having to ask permission from the person or company that built it?

The one-person problem

Technology projects often develop around one person who knows how everything works. They know why one folder must never be renamed, which copy of the spreadsheet is actually authoritative and which password nobody else realised was important. The system can look perfectly healthy while that person remains available.

Then they leave.

The problem is not unique to Māori GIS, but it can be particularly damaging where technical capacity is limited and specialist help is expensive. A system that requires one external person every time something changes is not necessarily the sustainable capability it appears to be.

This is where ideas of succession and continuity became important. Knowledge should be capable of moving between people. More than one person should understand the system. The next generation of users should not inherit an unexplained black box. In Māori contexts, that intergenerational perspective resonated strongly with the idea that information is held within ongoing relationships rather than for one project cycle alone.

Kaitiakitanga also became relevant to how I thought about this, not as a simple Māori synonym for “stewardship”, but as a reminder that holding information brings responsibilities. Somebody has to care for it, protect it, understand its limits and make sure it remains usable for those who come after. A backup is a technical control. Knowing why the information matters and who should inherit responsibility for it is something broader.

Monday morning

The same problem appeared in training. A conference workshop can be excellent. The presenter knows the software, the examples are prepared, the internet works and the participant follows along. For an hour or two the technology looks straightforward. Then the participant goes home and discovers that their computer is locked down, their data is messy, the menu looks different and the person who approved the training is already asking why the finished system is not ready.

Monday morning is where capability gets tested.

This is why the work between conferences became increasingly important to me. Through Māori GIS conferences, university teaching, DOC outreach, Managing Māori GIS Projects workshops and later Indigenous Mapping Wānanga, the most useful question was often not “What can we teach during the event?” but “What will help people continue afterwards?” Project planning became as important as button clicking. Data access mattered. Software cost mattered. Organisational ownership mattered. Support after the workshop mattered.

The Māori idea of ako helped me understand another part of this. Learning did not need to move only from trainer to participant. The best sessions were often those where people brought their own knowledge, challenged an example, corrected an assumption or showed another way of solving the problem. A trainer might know the software while a participant knew the whenua, the local history or the practical constraints. Capability grew when both kinds of knowledge were allowed into the room.

Being corrected therefore became one of the better signs that a session was working. It meant the relationship was not simply expert and recipient. People were becoming confident enough to question the map and the mapper.

Wānanga and practice

The Indigenous Mapping Wānanga from 2014 onward made this even clearer. Participants brought real projects and practical questions. International Indigenous mapping experience, Māori organisations, government agencies and technical trainers all contributed. The value did not come from promoting one platform. It came from bringing tools and support closer to kaupapa people were already working on.

The form of wānanga also mattered. It created space for discussion, questions, examples and relationships in a way that a conventional software course often does not. People could learn from one another rather than only from the person at the front. Manaakitanga mattered too in the practical sense that people had to be welcomed, supported and given enough confidence to ask questions without feeling they were exposing a lack of technical knowledge.

By 2017 and 2018 the wānanga used a wider mix of technologies. Google mapping tools sat alongside QGIS, Survey123, Mapbox and other approaches. This mattered because capability built around one vendor can easily become another form of dependency. A person who understands geographic concepts, data structure, provenance and project design can move between tools much more easily than someone who has only memorised one workflow in one product.

The Claudelands Wi-Fi problem in 2017 also made the point efficiently. A workshop built around modern cloud tools became much harder when the venue internet struggled. The technology was globally available but locally inaccessible. Access always depends on infrastructure, and the environment matters as much as the tool.

Ngā Poutama

Ngā Poutama Matawhenua took this further because the programme itself was built around continuity rather than a one-off event. By 2020 practical online Māori GIS wānanga were running regularly. Participants could attend sessions that matched their needs, return with questions and use a mix of platforms depending on the task.

The name Ngā Poutama also suited the way I had come to think about capability. People do not all need to become professional GIS specialists. They may need different steps for different kaupapa. Someone working on environmental monitoring needs one set of skills. Someone working with historic imagery may need another. A hapū building local GIS capability may need enough understanding to maintain information, decide what is public and know when outside specialist help is required.

The programme also made another principle explicit: we will never ask you for your data. That was partly about Māori data governance and rangatiratanga, but it was also a capability principle. Training did not have to be built around taking possession of participants' information. Methods could be demonstrated with sample data while real information remained under local control.

A good capability programme should make the participant more independent, not make the programme itself indispensable.

Open tools and choice

The growth of QGIS has been particularly important because open-source software removes one major barrier. A community can install a capable desktop GIS without beginning by securing an enterprise licence budget. That does not mean QGIS is culturally preferable or automatically the right answer. It means people have another choice, and choice supports independence.

The same is true of public data services. LINZ, councils, Stats NZ, environmental agencies and others now make large amounts of spatial information available in ways that would have seemed remarkable during the DVD period. This is a major improvement, but access is only the first step. People still need to know which dataset is appropriate, what authority it carries and how it relates to their own knowledge.

A mature local GIS should be able to sit public government data alongside information held by iwi or hapū without pretending the two are the same kind of knowledge. The public layer may provide useful context. Local knowledge may carry a completely different authority and set of responsibilities. Capability includes understanding that distinction.

Local control

The idea of hapū GIS or locally controlled Māori GIS is now much more technically achievable. It does not necessarily require an expensive server environment. A practical system might combine QGIS, carefully organised local data, public web services, mobile collection tools, backups and a limited set of published layers.

The harder part is often governance. Who can edit? Who decides what is public? Who maintains the system? Where are the passwords? Can the data be exported? What happens when committee members change? Which material should never be placed in an external cloud platform? These questions can look mundane beside a beautiful StoryMap or 3D scene, but they are what make those products sustainable.

The question I increasingly ask is not only whether the system will work tomorrow, but whether it will still make sense to the people who inherit it. Will they know where the data came from? Will they understand what can be shared? Will the organisation still control its accounts? Will the system support the kaupapa or slowly force the kaupapa to fit the platform?

Architecture should follow purpose and authority, not the other way around.

AI and dependence

Artificial intelligence introduces a new version of the same question. AI can reduce technical barriers dramatically. A person can ask for help writing a script, cleaning data, explaining a GIS error or building a simple application. That can increase independence if it helps people understand and perform work themselves.

It can also create a new dependency if nobody understands what the generated code or answer is doing. The system may work because an external model generated something, but nobody can maintain it, verify it or explain why it produces the result it does. Capability therefore still requires understanding.

For Māori GIS there is an additional issue around information control. A convenient AI service may not be the right place for sensitive community information. The fact that a tool can process something does not mean it should receive it. Rangatiratanga over information has to remain part of the decision, even when the technology makes uploading the information almost effortless.

A different measure

Over time my own measure of success changed. I still care about good maps and enjoy solving technical problems, but the finished product is no longer the only thing I look for. Did more than one person learn how the system works? Can the organisation update the information without calling the original developer? Are the source files under its control? Does somebody understand the provenance? Can the data move to another platform? Is there a backup? Has the group decided what can be public and what cannot?

Those are signs of capability, but there is another sign I value just as much: has the relationship changed? Are people more confident to challenge the map, question the official dataset, ask what the vendor is doing with their information or decide that a layer should not be published? If the answer is yes, the project has left behind more than technology.

This is where whanaungatanga, ako, rangatiratanga and kaitiakitanga have influenced how I now think about GIS work. I do not claim those concepts as mine or pretend that a technical project embodies them simply by using the words. What I learned is that capability is relational, reciprocal, responsible and connected to authority. A system that ignores those things may still function technically, but it is missing much of what makes Māori GIS different from simply doing GIS with Māori data.

Looking back across claimant mapping, the marae GIS pilots, conferences, outreach workshops, Indigenous Mapping Wānanga and Ngā Poutama, the common thread is the gradual movement from delivering maps toward leaving capability behind. At first that meant maps and data, then software and computers, then training, networks and ongoing support. Increasingly it means helping people understand enough to choose their own tools, control their own information and know when specialist assistance is useful rather than permanently necessary.

The best technical expert is not necessarily the one who makes themselves indispensable. Sometimes the most useful thing you can build is a system that no longer needs you, but still carries the context, authority and relationships that made the work worth doing in the first place.

For the wider twenty-year story, see From DVDs to AI: twenty years around Māori GIS, mapping and capability. For the companion piece on uncertainty and authority, see State of Unknown.