Beyond the server room
By the late 2000s New Zealand GIS was already comfortable with servers. Councils, government departments, utilities and research organisations had spent years moving spatial data into shared databases and publishing maps through internal and public web systems. The next change was quieter: the organisation no longer had to own every piece of the machinery, and geographic information no longer had to arrive as a file. A dataset could be hosted on a shared platform, exposed through a web service, queried through an application programming interface, or harvested into another catalogue without anyone copying it by hand. The server room was becoming less of a geographic requirement.
The earlier enterprise model remained important. Most organisations still needed authoritative databases, controlled editing, identities, permissions and staff who knew what their data meant. The boundary around the system expanded. A service running outside an agency data centre could still deliver the agency’s data. A public application could ask another organisation’s endpoint for a layer when it needed it. A catalogue could collect metadata automatically from several providers. Geography was becoming something software could request from the network rather than something a GIS user always downloaded, stored and opened locally.
The language became slippery. A web map, an Internet-facing server and a hosted cloud platform described different arrangements. Some systems were software as a service, some ran on provider-managed infrastructure, some remained on premises while exposing public endpoints, and many combined several arrangements at once. By 31 December 2025 New Zealand geospatial practice was thoroughly hybrid. The useful history lies in how those combinations changed distribution and reuse.
From 2021 NZTA and Eagle worked on a proof of concept and implementation of ArcGIS Enterprise on Kubernetes. The customer case identifies on the NZTA side and at Eagle. Its hub-and-spoke model placed shared authoritative data and platform governance with a central spatial capability, while business teams developed applications and workflows around those services. The case describes connections with asset management, safety and investment systems, alongside dashboards and field data collection. Kubernetes changed how the platform was deployed and scaled, while service ownership and reliable access continued to depend on the organisation operating it.
A New Zealand spatial marketplace
provided an early local example of a different distribution model. The company was legally registered in September 2005, but contemporary reporting dates the recognisable online platform from 2007, with a private beta released in November 2007 and a public beta in April 2008. The New Zealand Herald described it as an online marketplace for high-quality map data aimed at professional users such as GIS analysts, surveyors, architects and engineers. replaced some of the familiar distribution routine of phone calls, email, physical media and one-off delivery with a site through which datasets could be found, purchased or shared.
The service preceded later open-data releases. Some of the original proposition concerned commercial data and paid distribution, and Chapter 33 describes the changes in licensing and Crown pricing that made more data freely reusable. A data custodian did not necessarily need to build and maintain its own complete public distribution website. Data could sit on a common hosted platform with search, metadata, preview, export and later service interfaces supplied as part of the platform.
That arrangement also shifted responsibility. The data owner still had to decide what to publish, describe the dataset, maintain its content and set appropriate access conditions. The platform provider dealt with more of the delivery environment. That division became increasingly attractive as the number and size of public datasets grew, especially for organisations that wanted reliable distribution without becoming specialist web-hosting businesses on the side. The humble spatial download site was beginning to behave more like infrastructure.
LRIS and LDS
The Land Resource Information Systems Portal turned that model into an institutional service in 2010. Manaaki Whenua records the first LRIS Portal release as being developed with , providing access to land-resource information that had previously been distributed through more specialised channels. The LINZ Data Service followed in 2011. A 2012 government case study described LDS as providing national datasets through downloadable formats and web services, and a June 2013 government announcement said it had more than 5,600 registered users and more than forty free and open fundamental datasets.
Those services changed the public face of national spatial data, but the backend change was just as useful. The same platform pattern could serve different custodians while allowing each organisation to remain responsible for its own data. LRIS did not become LINZ, and LINZ did not become the Ministry for the Environment. They could nevertheless use a common delivery environment. By 2017 the platform was also serving the MfE Data Service, Datafinder, GEOINT New Zealand Data Service, Canterbury Maps Data Service and other New Zealand publishers.
The growth of these portals made an older distinction more obvious. Publishing a file lets another organisation make a copy. Publishing a service allows another system to depend on a maintained endpoint. The copy is under the consumer's control but can become stale. The service can remain closer to the publisher's current data but introduces a dependency on connectivity, provider availability, authentication and interface stability. Neither model is automatically better. New Zealand organisations increasingly used both options.
The service moves to the cloud
In 2017 that platform model became explicitly cloud based for three important national services. support material states that the LINZ Data Service, the LRIS Portal and the MfE Data Service migrated from on-premises installations to a cloud installation. Users were moved to a common ID so the same account could work across sites on the platform. The migration changed hosting arrangements and part of the identity model.
LINZ's 2017/18 annual report independently confirms the move for LDS. It states that the service moved to a cloud-based platform in September 2017 to improve sustainability and scalability and to respond more quickly and cost-effectively to demands for additional storage. This account concerns LINZ’s public distribution service. Selected workloads moved to hosted infrastructure where it solved a delivery problem, and the arrangement gradually became routine.
The migration also exposes the new dependency created by convenience. User identities had to be migrated. Applications and workflows that relied on a service needed the service to remain reachable. A provider-controlled environment could change authentication, storage, interfaces or commercial terms in ways consumers had to absorb. Hosted platforms removed some infrastructure work from individual agencies, but they did not remove governance, business continuity or the need to understand what other systems depended on the service.
From SDI blueprint to service ecosystem
Spatial Data Infrastructure developed through catalogues, services and connections between custodians. New Zealand's SDI work had emphasised common metadata, catalogues, standards, distributed custodians and interoperable services. Chapter 40 documented the metadata-standard problem directly: the 2007 Wildfire Threat Analysis review found that the chosen New Zealand standard lacked usable read-and-write tooling, leading to a Word-template workaround and the rewriting of existing metadata.
The standards lineage continued. Government later endorsed the ANZLIC Metadata Profile, ISO standards evolved, and consistent descriptions still supported discovery. The implementation model became more pragmatic. In 2016 data.govt.nz reported that most agencies lacked the capacity to run their own catalogue or hosting infrastructure. Its beta catalogue therefore supported central hosting as well as metadata harvesting from CSW, CKAN and data.json sources, including ArcGIS-based catalogues, using a DCAT-based schema mapped to ANZLIC.
This pursued the same objectives through adapters and shared services rather than requiring every agency to implement the complete standards stack in the same way. Later data.govt.nz guidance described automated harvesting from ArcGIS Online, allowing information maintained in an ArcGIS item to flow into the national catalogue. Formal standards still sat underneath parts of the process, while ordinary publishers could work through platform fields, templates and automated connectors rather than hand-building ISO metadata records.
The national SDI therefore developed as a distributed environment. Discovery, standard descriptions, maintained services and access to authoritative data were delivered through several hosted platforms and service interfaces rather than one operational national platform. ArcGIS Online, , OGC services, catalogue adapters and REST interfaces each covered part of the problem.
Applications call geography
The next step was to stop treating a service merely as a map to be viewed by a person. In July 2013 the New Zealand Walking Access Commission made its Public Access Areas layer available through Esri feature and map service REST endpoints. In a public data request opened in 2012, a user asked for vector data that could be used away from mobile coverage. The Commission's 2014 response recorded that the endpoints had been available since July 2013 and could be used to access the national public-access layer.
That small example captures the change well. A map service could draw the information for a browser, while a feature-oriented endpoint could expose geographic features to software. A developer or another GIS application could work with the maintained service without first asking the Commission to email a current copy. Connectivity still constrained offline work, while the same authoritative layer could now serve more than one interface.
Founded in its recognisable form in 2007 by and , was moving in the same direction. By March 2017 the company was promoting its Query API alongside government data services on the platform. Its contemporary Datarama material said datasets on Datafinder and other -powered sites could be accessed using the query API. The platform later exposed vector, raster and set-query interfaces as well as OGC and Esri-compatible services. Data distribution was no longer limited to choosing a download format. Software could ask a location-specific question and receive data in return.
Contemporary 2008 coverage described that change in almost physical terms: was replacing a distribution process built around DVDs, telephone calls, mail and email with a web platform, and named as its first distributor. Independent practitioners and small firms helped connect new platforms to an existing professional market before those platforms became part of national data infrastructure.
Data services
Once software can call spatial information directly, a visible map is optional. A property application may ask for the parcel containing a coordinate. A field system may request the attributes of a nearby asset. A website may retrieve a geometry and draw it inside an interface designed for a completely different business task. The consuming application may use location to make a decision and never show the user a conventional map at all.
Chapter 35 followed maps disappearing behind task-specific applications. Spatial services extended that approach by letting applications request data directly. The application does not need to know how the source database is administered, and the data provider may never see the final interface. What has to remain stable is the contract between them: identifiers, fields, geometry, authentication and the behaviour of the endpoint.
That stability is harder than a browser interface can make it look. A human user can usually recover when a button moves or a label changes. Software may fail immediately if a field is renamed, an endpoint disappears or authentication changes. API-based geography therefore increased the value of documentation, versioning, deprecation policies and predictable schemas. The machine is remarkably literal, which is excellent when the interface is stable and less charming when somebody casually renames parcel_id on Friday afternoon.
Types of service
The word service covered several different technical arrangements, and the distinction affected what consumers could do. A rendered map service could return an image that was efficient for display but offered little direct access to the underlying features. A feature service could expose geometry and attributes that another application could query or, where permissions allowed, edit. Tiled services pre-rendered or cached map images so that large basemaps could be delivered quickly. Query APIs could return selected records or values in machine-readable forms such as JSON. Treating all of these as interchangeable obscures why one endpoint suited a public basemap while another could become part of an operational application.
New Zealand's hosted platforms increasingly exposed several of these routes at once. documentation describes OGC web services, Esri-compatible REST services and its own vector, raster and set query APIs. LDS also developed into a service where users could browse, export and obtain map or data interfaces from the same published source. This multi-interface model reduced pressure to choose one permanent distribution format for every consumer. A desktop analyst, web developer and automated process could reach the same published information differently, provided the custodian maintained the service and its semantics.
The service model also changed ideas about currency. A downloaded copy has a clear acquisition date, even if the user later forgets it. A live endpoint can appear perpetually current while actually depending on the publisher's update process. CRoSL specified weekly updates. Other services might update continuously, nightly, irregularly or only when a custodian republishes them. Consuming a service therefore did not remove the need to understand currency. It moved that question from the file on the user's disk to the provider's publishing workflow.
From WFS to application APIs
The early spatial-data-infrastructure vision leaned heavily on OGC interfaces. WMS was effective for drawing maps, WFS offered standards-based feature transfer, and catalogue services supported discovery. The Canterbury earthquake recovery SDI showed that a standards-based service architecture could support a large multi-agency programme when dedicated funding, governance, custodians and technical staff were available.
National application delivery posed a different problem. WFS implementations varied between products, GML responses could be heavy, and interactive browser or mobile applications often needed smaller, faster and more predictable responses than a general feature-transfer service provided. REST-style feature services and JSON APIs fitted application development more naturally, while cached and tiled services, including WMTS-style delivery, suited responsive basemaps. By the later 2010s these interfaces carried much of the practical web-application load that earlier SDI designs had expected standards-based feature services to handle.
WFS still had a useful place for standards-based feature exchange, just as WMS remained valuable for interoperable map display. The working architecture became plural: REST or platform APIs for interactive applications, tiles for fast basemaps, downloads for bulk transfer, and OGC services where the consumer needed them. New Zealand's operational SDI emerged as a collection of compatible routes rather than a single WFS-centred national implementation.
Standards meet local incentives
National standards also faced an incentive problem. The benefit of a common schema, metadata profile or feature definition appeared at system level after several organisations adopted it. The cost arrived locally and immediately through staff time, data remodelling, system changes, testing and continuing governance. A council gained little day-to-day value from reshaping a working asset, property or planning dataset solely to satisfy a voluntary national schema unless the exchange solved a problem it already had.
Staffing and GIS capacity differed substantially between participating organisations. The project record spans Christchurch's ten-person GeoData Services product-delivery team and 's single GIS administrator. A national standard could therefore reach one organisation as a specialist team assignment and another as extra work for one person already supporting operational GIS. Under tight FTE constraints, standards work competed with rates, property, assets, planning, emergency response, data maintenance and ordinary map requests.
Hosted platforms partly reduced that burden by moving standards work into product interfaces, adapters and APIs. The national catalogue could harvest ArcGIS Online metadata; could expose several service types from one published dataset; a council could participate through a platform it already used. Publishing tools made standards compliance part of routine work.
From standards to adapters
Standards remained part of the service ecosystem. OGC interfaces, common coordinate reference systems, stable identifiers, GeoJSON-style geometry, catalogue schemas and consistent metadata all made it easier for one system to consume another's information. Hosted platforms reduced how much of that complexity an ordinary publisher had to handle directly. A platform could generate a service endpoint, expose several formats and translate item descriptions into fields another catalogue could harvest. Much of the standards machinery was being embedded in products and connectors instead of presented to every data custodian as a manual compliance exercise.
Data.govt.nz offered different catalogue arrangements in 2016 to suit agencies’ technical capacity. Agencies with their own catalogues could expose CSW, CKAN or data.json feeds and allow the national catalogue to harvest them. Agencies without that capability could use the central catalogue and hosting service instead. The model explicitly accepted uneven organisational capacity. That was a better fit for a public sector ranging from large technical agencies to small organisations with thinly staffed spatial functions.
An agency already managing spatial items in ArcGIS Online could maintain titles, descriptions, licences and other metadata there, then allow harvesting into data.govt.nz. The national catalogue could avoid duplicate entry and the agency could retain its working platform. The adapter between systems carried part of the interoperability burden that earlier standards programmes had often left with individual staff.
Hosted GIS becomes a platform
By the 2010s hosted GIS platforms were also becoming application environments rather than simple data stores. ArcGIS Online is one prominent New Zealand example and one platform within the wider geospatial environment. Hosted feature layers, identities, permissions, forms, web maps, dashboards and configurable applications could be assembled without an organisation operating each server component directly. Small teams could therefore build a coherent system quickly, while concentrating more capability, cost and dependency in the platform itself.
The 2020 Manaaki service used Survey123 forms, an ArcGIS Online feature layer, controlled users and permissions, web maps, applications, dashboards and a supporting website. Its operating plan included backup and migration so the service could continue when ownership or hosting arrangements changed.
Manaaki belongs principally to the health and application chapters, so the community programme only needs its architecture here. A single hosted environment could provide capture, storage, mapping and dashboard functions that previously might have required several locally managed systems. Technical work shifted into configuration, identity, permissions, data design, integration and platform governance.
A maintained endpoint
The Central Record of State Land also supplied maintained information through services. LINZ began developing CRoSL in 2019 and released the full tool in late 2020. LINZ describes the dataset as being updated weekly and made available through a web viewer, downloadable data and a REST API. One maintained record could therefore serve a person exploring the map, an analyst wanting a local copy and software needing a direct service connection.
Users could obtain files or connect to data through APIs. Downloads did not disappear when services became available. They remained useful for offline work, reproducibility, large analysis jobs and situations where the consumer needed control over a fixed snapshot. Services were useful when currency and direct integration were more valuable. Mature distribution increasingly offered several routes to the same maintained information.
The same choice could appear inside one organisation. An authoritative database might remain on premises while selected layers were replicated to a hosted platform. Sensitive editing might stay internal while public data was exposed through a cloud service. A mobile application could cache data for offline use and synchronise later. By the early 2020s, organisations were maintaining hybrid architectures to meet their requirements.
Access crosses the boundary
Hosting also changed the location of access control. Earlier internal GIS could often assume that being on the organisational network was itself part of the security boundary. Public and hosted services needed clearer distinctions between anonymous users, registered users, trusted applications, editors and administrators. ID in the 2017 migration is a simple example of that shift: the same hosted identity could operate across several sites, while the data services remained organisationally distinct. ArcGIS Online used its own accounts, groups and sharing controls. APIs could require keys or tokens even when the underlying data was public.
Those mechanisms made external reuse easier, but they also created more credentials and permission decisions to manage. A public dataset might allow anonymous viewing while restricting editing. A partner organisation might receive access to material that was not public. An automated application might need a key that should not be embedded carelessly in a public page or shared between unrelated systems. Chapter 40 treated identity as part of enterprise GIS. In the hosted period, identity increasingly had to work across organisational and platform boundaries rather than stopping at the office network.
Operating spatial services
Cloud and hosted platforms redistributed operational responsibility rather than abolishing it. An organisation running its own stack had to worry about servers, operating systems, storage, database software, GIS servers, patching, capacity, backup and much of disaster recovery. A hosted provider could take responsibility for some of those layers. That could reduce the amount of infrastructure an individual agency had to build and maintain, particularly for public distribution or rapidly assembled applications.
Other responsibilities stayed with the data owner. A provider cannot decide whether a boundary is authoritative, whether a field should be public, whether a service can tolerate downtime, or whether a dataset is appropriate for a particular decision. Permissions still need design. Schemas still need governance. Backups still need thought, even when the provider supplies technical recovery features. Organisations remained responsible for the information they hosted.
Cost also changed shape. Capital purchases and some perpetual licence models were joined or replaced by subscriptions, hosted storage, service tiers and consumption-based charges. Entry could become easier because organisations could publish without buying infrastructure first, while recurring fees and dependence on vendor pricing became more visible. Cloud GIS costs varied with the service, workload and support arrangements. The main shift concerned which costs were visible, who carried them and how quickly capacity could be added.
Dependencies become visible
The 2017 migration is useful again here because it required users to migrate identities across three services. That is a modest inconvenience compared with rebuilding a GIS platform, but it reveals a structural fact. Once several organisations and applications consume an external platform, changes made by the platform can propagate widely. Authentication, service URLs, supported formats and subscription features become part of other organisations' operating environment.
Hosted services can remove duplication, improve capacity and make specialised infrastructure available to organisations that would struggle to build it themselves. This concentration extends the shared-service risk described in Chapter 40 across organisational boundaries. Shared services are useful precisely because many consumers can rely on them, making reliability, communication and change management part of the geographic service.
The same principle applies to open standards. OGC services can reduce dependence on one client product, while individual implementations still vary and endpoints can disappear. REST-style services are often straightforward for application developers but can expose platform-specific structures. APIs range from well documented to mysterious. Interoperability became a practical exercise in maintaining stable agreements between systems rather than choosing one perfect standard.
Geography between machines
By the early 2020s New Zealand practitioners were routinely discussing ArcGIS Online, ArcGIS Enterprise, mobile geodatabases, imagery services, cloud infrastructure and other platform technologies at regional professional events. In a 2020 survey of New Zealand plantation forestry companies, 91 per cent of respondents used the LINZ Data Service, 78 per cent used , 57 per cent used LRIS and 52 per cent used the MfE Data Service. The figures apply to the surveyed forestry organisations, while confirming that hosted national data portals had become ordinary working infrastructure in that sector.
The deeper change was geographic information moving routinely between machines. A data owner could publish once and allow several applications to consume the result. A catalogue could harvest descriptions automatically. An API could answer a spatial query while a hosted form wrote directly to a managed feature layer. The work of the GIS specialist shifted towards designing those relationships and protecting the meaning of the information as it crossed them.
That required skills that sat between traditional GIS and general information technology. Practitioners needed to understand service URLs, authentication, hosted storage, permissions, schemas, identifiers, web-service behaviour and failure modes. They did not all become software developers or cloud engineers. They increasingly had to recognise when an apparently simple map or field form depended on a chain of external services and know which part of that chain they actually controlled.
Cloud operations
By 31 December 2025 cloud platforms, hosted data services and APIs sat alongside desktop GIS, enterprise databases, specialist network systems and files throughout New Zealand's geospatial environment. Working systems often combined these approaches, using a local database for controlled editing, a hosted service for public distribution, downloadable files for analysis and an API for software integration.
The earlier SDI goals took shape through platform forms, automatic metadata harvesting, hosted publishing, OGC services, REST endpoints, APIs, shared schemas and catalogue adapters. Each approach helped make spatial information easier to discover, maintain and reuse.
That architecture also prepared the ground for a different kind of map. When services can be updated continuously and applications can consume them immediately, geographic information can support live operational pictures rather than periodic products. Sensors, earthquake feeds, emergency reports, rapid imagery and changing access information can move into the same environment. Chapter 42 follows that development through GeoNet, Canterbury, Kaikōura and Cyclone Gabrielle, where the value of connected mapping was repeatedly tested against the inconvenient fact that disasters also break networks. New Zealand’s NZTA ArcGIS Enterprise on Kubernetes case is described in Chapter 40.
Chapter source notes
1. Koordinates chronology is controlled by contemporary and platform records: the company was registered in 2005, while the recognisable hosted platform emerged in 2007, with private beta in November 2007 and public beta in April 2008. The chapter treats the early service as a hosted spatial-data distribution model that initially included commercial as well as later open data. It does not back-project the mature open-data platform onto the 2008 product.
2. Manaaki Whenua records the first LRIS Portal release with Koordinates in 2010. Official LINZ and government material place the LINZ Data Service launch in 2011. Chapter 41 uses these services to show hosted distribution and service delivery; Chapter 33 discusses the open-data and licensing history.
3. Koordinates support documentation and LINZ’s 2017/18 Annual Report independently support the September 2017 migration of LDS to a cloud platform, while the platform documentation also covers LRIS and the MfE Data Service and the shift to Koordinates ID. This evidence applies to those public data services and does not establish that the parent organisations moved all GIS systems to cloud infrastructure.
4. Data.govt.nz’s August 2016 technical update is the principal evidence for pragmatic catalogue interoperability. It records a DCAT-based schema mapped to ANZLIC and harvesting from CSW, CKAN and data.json sources including ArcGIS, while acknowledging that most agencies lacked capacity to operate their own catalogue or hosting infrastructure. Later data.govt.nz guidance supports automatic harvesting of ArcGIS Online item metadata. This is the basis for the interpretation that practical SDI functions increasingly appeared through platforms, harvesters and adapters rather than a single national technical stack.
5. The New Zealand Walking Access Commission’s 2014 response documents Public Access Areas feature and map service REST endpoints available from July 2013. LINZ’s Central Record of State Land documentation supports the late-2020 full release, weekly update cycle and simultaneous web-viewer, download and REST API access. These cases illustrate machine-to-machine geography without claiming a national first or treating every REST endpoint as a general-purpose API.
6. De Gouw, Morgenroth and Xu’s 2020 plantation-forestry survey supports the late-period normalisation of hosted national data portals among respondents: LDS 91 per cent, Koordinates 78 per cent, LRIS 57 per cent and MfE Data Service 52 per cent. These remain sector-specific survey results and are not national adoption rates.
The NZTA and Esri case study provides a New Zealand example of the move to ArcGIS Enterprise on Kubernetes, with operational governance and shared-service responsibilities continuing in the cloud-native environment.