Utility networks

Network connections

An electricity cable, telephone circuit, water main or gas pipe can be drawn perfectly on a map and still be a poor network record. Operators need to know where it is, but they also need to know what it connects to, which equipment sits at either end, what happens at branches and switches, and which customers or downstream assets depend on the path. A line that ends a few centimetres short of the correct node on screen may look harmless while breaking the digital connection that allows a system to trace the network. Utility GIS therefore developed around a different problem from ordinary thematic mapping. Geometry had to carry the structure of the physical system as well as its position.

New Zealand network operators entered the 1990s with large stores of geographic information, much of it on paper. Electricity plans showed cables, poles, substations and transformers. Telecommunications records documented ducts, cables and connections. Water and gas operators maintained plans of mains, valves and associated plant. These records had been produced for engineering and maintenance work rather than for GIS, and they were rarely waiting in one consistent digital form for somebody to import.

Turning them into a network database involved more than tracing lines. Paper plans had to be reconciled with textual asset registers, field knowledge and newer as-built information. Assets needed stable identifiers. Junctions and branches had to be represented consistently. Where records disagreed, somebody had to decide which source to trust or send staff into the field to check. The conversion workforce included GIS staff, engineers, technicians, data-entry and quality-assurance staff, contractors and field crews, many of whom are not individually named in public records.

Once converted, the data acquired a maintenance obligation. New subdivisions added network. Old equipment was removed or replaced. Cables were rerouted, valves changed, transformers upgraded and connections altered. A digital network that was not updated could become more dangerous than an obviously old paper plan because the screen gave every line the same clean appearance. Utility GIS therefore tied mapping to asset management from the start.

Paper plans become a register

Vector converted paper network records into GIS. Its 1999/2000 Asset Management Plan says GIS implementation began in the early 1990s and involved extensive conversion from existing paper records together with field data capture. The programme included data conversion, system development and changes to working methods. It was a long conversion process in which the company assembled a usable digital representation of its electricity network before later moving that information into a new platform. Years of network history had first to be found on paper, interpreted, entered and checked. Buying the software was the part that came with an invoice; converting the network was the part that became the work.

The same plan described the GIS as a comprehensive register of Vector’s network assets, represented both geographically and in text. That wording is more precise than calling it an electronic map. A pole, cable or transformer existed in the system as an asset with attributes as well as a shape or point on screen. The geographic record could be connected to information about the equipment itself, and the asset could be referred to consistently in planning, maintenance and analysis.

Staff retained source plans for reference after digitising features. They determined what could be captured and how reliable the initial geometry was. Field capture was used alongside conversion because records on paper did not always correspond neatly with what was in the ground or on the street. A network assembled over decades had been modified by maintenance, development and emergency work, and not every change had travelled through every record system with equal speed.

The early conversion therefore created both a database and a quality programme. Every feature entered into the GIS had to be assigned to the correct type, location and relationship. Missing or uncertain assets remained a data problem after digitising. Later Vector plans continued to refer to improving data quality, showing that conversion became an ongoing maintenance task rather than a once-only clean-up completed when the first network appeared on screen.

Shared utility studies, 1989–1996

The Centre for Advanced Engineering began its Wellington lifelines study in 1989 and completed it in 1991. Christchurch’s project followed in 1993, extending assessment to several natural hazards. Wellington also established an ongoing lifelines group in 1993. These initiatives brought utility operators, engineers and scientists together to examine the vulnerability of services and their dependence on one another.

Writing in June 1997, Wellington group project manager David Brunsdon identified GIS overlay of infrastructure networks and seismic hazards as an important development during this period. Water, wastewater, electricity, gas and telecommunications shared this geographic problem. The study dates establish the collaborative programme; they do not date every participant’s GIS installation.

Auckland lifelines, established in 1996

Auckland Regional Council initiated the Auckland Engineering Lifelines Project in 1996, involving about 40 organisations. It brought water, wastewater, power, gas and other services into a shared assessment of hazards and interdependence. Michele Daly and David Johnston’s later account describes hazard and infrastructure maps alongside workshops in which utilities assessed vulnerability and recovery.

The project began within the 1987–1996 period; its reports and developed assessment belong to 1997–2000. The mapped work is evidence about that programme, rather than proof of a completed GIS implementation in 1996. Vector’s 1999 asset plan separately records participation in the Auckland project.

Wairarapa lifelines, established in 1996

The Wairarapa Engineering Lifelines Association was formed at a Masterton meeting on 21 June 1996. District councils, Wairarapa Electricity, the regional council and other services were represented. Its later project report describes Wellington Regional Council’s Wairarapa office providing GIS support and says geographic services were still developing when the project began.

The report’s later participant list includes telecommunications providers. Those later company names cannot all be read as the membership of the founding meeting. This regional collaboration adds a documented utility contribution while leaving individual operators’ first GIS adoption dates open.

Smallworld at Vector

In late 1998 and early 1999 Vector converted its accumulated geographic and textual network information and functionality to the Smallworld GIS environment. The 1999/2000 Asset Management Plan describes this migration, following the record conversion that began in the early 1990s.

Smallworld reached Australasia through an overseas software business. Mike Bundock’s company biography records his work with Smallworld in the United Kingdom before establishing an Australasian operation in 1993. That regional operation date is separate from Vector’s documented migration in 1998–99 and does not establish the first New Zealand installation.

Smallworld was designed around networked infrastructure rather than only general desktop mapping. Its attraction to utilities lay in the way a physical system could be represented as connected objects with business rules and engineering relationships. For an electricity distributor, the relationship between conductor, switch, transformer, pole, substation and customer was part of the data model. A user could work with a network rather than a collection of lines that happened to share the same map.

Vector’s asset-management documentation places the GIS among several systems used to manage condition and performance. Contractors could have systems for daily work scheduling, while Vector maintained records of faults and maintenance histories against individual assets. The GIS supplied the geographic and textual asset register within that wider environment. Network information could therefore be used for planning and maintenance without requiring every function to be stored inside the GIS itself.

By 2005 Vector was documenting further integration. Planned work included a GIS/SAP asset-register connector, wider use of aerial imagery and continued improvement of data quality. Network models were exported into specialist engineering-analysis applications. The GIS was becoming one source within a set of operational systems rather than a self-contained mapping application.

Network topology and tracing

Topology in a utility network is practical rather than decorative. An overhead electricity line can cross another line on a map without being electrically connected to it. A cable can pass beneath a road, join a transformer and continue as another circuit. A switch can change which part of the network is energised. Representing these relationships requires the data to distinguish a crossing from a connection and to record the devices that alter the path.

The same principle applies to other networks. A water main branches through valves and junctions, and closing one valve can isolate a section while leaving another supplied. A gas system has mains, pressure zones, regulators and valves whose arrangement affects flow and capacity. Telecommunications networks depend on physical routes through ducts, cabinets, cables and connection points. Each sector uses its own engineering rules, but all require the GIS to know more than where the line was drawn.

This is why a network database can fail while still looking plausible. A cable may be snapped to the wrong node. Two water-main segments may stop just short of one another. A switch may exist graphically but be associated with the wrong circuit. In an ordinary map these errors may be hard to see. In a trace, isolation calculation or exported network model they can produce an obviously wrong result.

Network GIS therefore moved quality assurance into the structure of the data. Geometry, connectivity and attributes had to agree. The database could enforce some rules automatically, but many errors still depended on people who understood the physical network. Engineering knowledge and GIS data management were forced into closer contact than in applications where a line mainly represented a boundary or thematic feature.

One asset, several systems

The map was only one place where a utility asset existed digitally. A transformer might also appear in a financial register, maintenance system, fault history, inspection database and engineering model. If each system used a different identifier, staff had to infer that several records referred to the same piece of equipment. A stable asset identifier provided a cleaner link between them.

Vector’s later documentation shows this architecture becoming explicit. SAP held asset and maintenance information, while Smallworld provided the geographic network record. Network information could also feed specialist electricity-modelling tools and distribution-management systems. The same physical asset therefore appeared through several technical views, each built for a different part of the business.

This arrangement reduced the need to force every attribute into the GIS. Finance could remain responsible for financial records, maintenance systems for work history and SCADA for operational telemetry. The GIS could remain authoritative for geographic and network relationships while sharing a common asset identity with the other systems. Integration worked when the systems agreed about which physical object they were describing.

The alternative was duplication. If a transformer was renamed or replaced in one system but not another, reports could diverge. If a cable geometry was corrected without the related asset link being maintained, the map and maintenance history could separate. Network GIS therefore moved progressively towards master-data disciplines that later enterprise systems would formalise more heavily.

In 2005 NIWA’s Craig Thompson, Tom Clarkson and Warren Gray described a GIS risk-assessment tool developed for Transpower’s electricity pylons. The tool combined land cover, slope, proximity to rivers and river size to rank the structures nationally for exposure to flooding, scour and slips. Its results were checked against sites already known to be at risk. This gave a transmission owner a way to direct attention across a large network when several hazards could affect the same asset. The same NIWA account describes support for helicopter laser surveys of high-voltage lines. Meteorological observations at intervals of 10 or 20 kilometres and detailed three-dimensional weather modelling helped interpret individual spans. GIS analysis, laser measurements and weather science were being used together in decisions about transmission infrastructure.

The 2005 earthquake-risk report prepared for Environment Canterbury by P. Brabhaharan, Robert Davey, Francis O’Riley and Leonard Wiles documents a difficult exchange of network information. Telecom kept Christchurch assets in Smallworld GIS and restricted release of its complete underground cable network. Earlier studies had received incomplete CAD extracts, and by 2005 the report described the loss of the earlier in-house drafting capability. Smallworld could translate layers and attributes, but producing a disconnected selection from the network remained difficult. The proposed workaround was to trace selected printed GIS output back into CAD. TelstraClear was willing to provide selected GIS information under confidentiality, while Transpower and Orion also held network information that could contribute to the assessment. The risk team’s method depended on access permissions and the structure of the utility database.

Utility and transport records also preserve the people doing the integration work. Transpower’s Alaina Dalzell presented georeferencing substation assets to improve data quality in 2017, while NZ Transport Agency staff Katie Dooley and Emma Winthrop presented GIS collaboration with the North Canterbury Transport Infrastructure Recovery alliance after the Kaikōura earthquake.

Wellington Electricity rebuilds the links

Wellington Electricity’s 2009 Asset Management Plan records this problem at the point of organisational separation. The company was migrating asset-management data previously held by Vector into its own systems. The plan described the migration as continuing through 2009 and stated that the inherited asset data was believed to be of good quality. The new environment had to preserve that information while connecting it to systems owned and operated by the new company.

The planned GIS was GE Smallworld, the same network platform used by Vector. Wellington Electricity described it as a representation of fixed system assets over a map of the supply area and as the primary repository of network asset data. It was intended for planning, design and operation as well as locating faults. The plan included GIS in routine network work.

The most useful detail is the identifier. Other specialised asset-information systems, including SAP, were to interface with the GIS using a unique asset identifier common across the systems. That design allowed maintenance records and spatial records to refer to the same equipment without relying on names or manual matching. The identifier tied the map to the asset-management process.

The plan also proposed an interface between GIS and SCADA so that the GIS could display the status of switching devices monitored by the operational system. SCADA remained responsible for monitoring and control. GIS supplied the network and geographic context. Connecting them allowed a user to view operational device state against the asset model, while each system retained its own functions.

The Wellington case also records the durability of network data across corporate boundaries. The electricity network had not changed ownership by being redrawn from scratch. Its accumulated digital record moved from Vector into Wellington Electricity’s systems. Platform compatibility helped, but the harder requirement was retaining identifiers, asset history and network relationships during the migration.

Watercare joins map and maintenance

Watercare provides a comparable case from a network whose physical behaviour is different. The 2009 study Spatial Information in the New Zealand Economy described Watercare as using GIS to integrate asset information, including non-spatial data. Staff had access to a spatial portal on their desktops, while maintenance crews used GIS on handheld computers that synchronised periodically with the network. The organisation maintained six GIS staff at the time of the study.

The field users carried more than a map. Job sheets and location information were available on the handheld devices, and crews could record work. The system also held photographs of assets such as valves inside manholes or sumps. A valve could therefore be represented by location, identifier, maintenance task and a photograph that helped staff recognise what they would find on site.

Watercare reported different benefits in the office and field. Office users avoided searching across several separate systems for asset information. Field crews saved time locating assets and reduced the need to have surveyors establish positions for routine work, while surveyors remained necessary where legal issues such as rights of way required higher certainty. The GIS sat between engineering records and work activity rather than replacing either.

By that date the operational model was mature enough to document: a maintained network, a spatial portal for general users, handheld access for crews and a specialist GIS team maintaining the information behind both. Water and wastewater GIS had become part of asset management in much the same way electricity GIS had, even though the engineering rules differed.

Telecommunications at national scale

Telecommunications networks create another demanding inventory problem. Copper, fibre and other physical infrastructure run through ducts, cabinets, exchanges and connection points, often with many individual paths sharing the same route. A network inventory has to record more than the street occupied by the cable. It needs enough connectivity and capacity information to relate physical routes to services and planned changes.

By about 2007, however, GE’s communications business publicly named Telecom New Zealand alongside operators such as Telstra, Deutsche Telekom and Swisscom as a major Tier One Smallworld customer. The service was being used for production-scale telecommunications work.

By the middle of the 2000s, a national telecommunications operator was using the specialist product family already established in electricity. Both sectors needed to maintain large physical inventories in which connectivity and asset relationships determined how the network could be used.

The field moves closer

Vector’s 2002 mobile project briefly shows what happened when the corporate network record was pushed out of the office. The company introduced forty Compaq iPAQs and six Panasonic Toughbook notebooks for field crews. The reported hardware and software cost was about NZ$200,000, with expected annual operational savings of roughly NZ$500,000. The figures belong to the specific project and should not be treated as general utility-GIS economics.

The equipment used two GIS families. Toughbooks ran the Smallworld environment used in the office, while the iPAQs ran Esri ArcPad. Vector wrote software to translate and synchronise information between ArcPad and Smallworld when the devices were returned to their cradles. The handheld users could record faults and inspections, while the rugged notebooks supported more detailed graphical updates such as new cable information.

GPS attachments gave the iPAQs a field position, while the corporate asset model supplied the features staff needed to find and update. The project reduced paper forms and duplicate data entry and gave crews access to plans without returning to the office. Mobile bandwidth was still too limited for the quantity of data Vector wanted to send, so the first design relied heavily on synchronisation rather than constant connection.

Chapter 34 follows the wider development of mobile GIS. At Vector, crews could take network information into the field and return observations to the system that supplied the office map.

Gas and the layered network stack

By the late 2010s Vector’s gas-distribution systems combined GIS with additional operational and enterprise platforms. Its 2018 Asset Management Plan placed GE Smallworld, ArcGIS, SAP, Siebel, SCADA and specialist network-modelling software within the same broad information environment. The products performed different jobs rather than competing to become one all-purpose GIS.

Smallworld carried network and asset relationships, while SAP supported asset lifecycle and maintenance processes. Customer and connection information came from other business systems. SCADA monitored operational conditions. Specialist modelling tools used network and demand data to examine pressure, flow, capacity and future constraints. ArcGIS supplied additional geospatial visualisation and analytical capability.

Vector’s system arrangements changed between its 1998 Smallworld migration and 2018. The specialist network GIS continued alongside additional operational, enterprise and analytical systems. The geographic database continued to supply a maintained representation of the physical network.

Gas also reinforces the distinction between a map and a network model. Pressure systems, regulators, valves and connected customers affect how gas moves through the system. A spatial line is only the visible geometry of that model. Operational planning requires the attributes and relationships that describe what the line carries, how it connects and what constraints apply.

Keeping the model current

A utility network changes every working day. New customers connect. Development extends mains and cables. Equipment reaches the end of its life and is replaced. Fault repairs can alter a route. Projects move from proposed design to constructed asset. Field staff discover errors that have survived for years in inherited plans. Every one of these changes can create a difference between the network in the ground and the network in the database.

Vector’s 2007 asset-management documentation records field data collection and verification applications for inspections, tests and defects. It also describes proposed networks transitioning to as-built status during the project lifecycle. A design drawing represents intended work; the asset register needs the network that was actually built.

The operator therefore needs a controlled process for accepting change. Engineering design, construction records, field verification and asset commissioning all contribute different information. Geometry must be updated, but so must identifiers, status and associated attributes. A new segment that appears on the map without entering the maintenance system is incomplete, and an asset created in finance without usable geographic or network relationships is equally awkward for operations.

The cost of stale data rises when more systems depend on the same network model. An error in a paper plan might inconvenience one crew. An error in a corporate network database can flow into planning, field work, analysis and other connected applications. The move to integrated GIS therefore made data governance more operational, not less.

The network as operational data

By the end of the 2000s, utilities were using GIS for network maintenance and operational work. Vector used Smallworld as a geographic and textual asset register, linked it with other asset and engineering systems and extended selected information into the field. Wellington Electricity designed common asset identifiers across GIS and SAP and planned an interface with SCADA. Watercare used GIS as an integrator of network information for office and field staff. Telecom New Zealand was operating Smallworld at national telecommunications scale.

The systems remained different because the networks were different. Electricity required electrical connectivity and switching logic. Water and wastewater required pipes, valves, direction, facilities and service relationships. Telecommunications required detailed physical inventory and paths through a complex cable network. Gas combined spatial connectivity with pressure and capacity modelling. No single generic line feature captured those operational differences.

The shared history lies in the data discipline. Operators converted legacy records, assigned identifiers, represented connectivity, linked the network to maintenance and business records, and then kept the result current as the physical system changed. GIS supplied the geographic structure, but the useful system depended on engineering knowledge, database maintenance and organisational procedures around it.

The work also pushed GIS further into ordinary infrastructure management. A fault dispatcher, maintenance planner or field technician might rely on spatial information without making a map. A financial system could depend on asset identifiers linked back to GIS. A network model could be exported into engineering software. The geographic database became one part of the operational record of the infrastructure itself.

Conservation and environmental management dealt with different kinds of geography: habitats, protected areas, species records, rivers, wetlands and changing ecological conditions. These systems shared the same growing dependence on maintained spatial databases, but their boundaries were often less physically fixed than a pipe or cable and the evidence came from a different mix of field observation, science and land management.