Desktop GIS

In the late 1980s a New Zealand organisation that used GIS could still have a fairly literal GIS room. A GIS installation could be somewhere you walked into, because the room contained a fair portion of the system. The more capable environments were built around minicomputers or Unix workstations, graphics screens, specialist storage, digitisers and plotters. ARC/INFO, Intergraph and other commercial systems could maintain large datasets and perform work that earlier purpose-built systems had shown was possible, but they were not ordinary office software. The people operating them usually knew the data structures, commands and hardware well enough to keep production moving when something failed.

That arrangement suited organisations that had enough spatial work to justify a specialist unit. Water and Soil moved the established NZLRI and LADEDA environment to ARC/INFO in 1988. The University of Canterbury had workstation ARC/INFO and ERDAS capability by 1989. Councils, science organisations and government departments were buying or planning systems that could maintain authoritative spatial databases rather than produce only individual maps. A planner, scientist or manager might use the results without ever touching the GIS terminal.

Personal computers changed that division gradually. They became capable of displaying useful maps, storing local datasets and running software designed for people who did not want to operate a full production GIS. Windows and graphical interfaces reduced the amount of command knowledge needed for routine work. Hard disks grew large enough to hold datasets that previously belonged on central systems, while network shares and CD-ROMs gave organisations new ways to distribute them. GIS began to appear on desks that had previously received only printouts.

The shift built on an existing digital base. New Zealand already had digital cadastre, topography, land-resource information, satellite imagery, census geography and scientific databases. The distance between those datasets and the person wanting to use them shrank. A desktop application could turn a centrally produced dataset into something an analyst could query and map directly rather than sending every request to a cartographic or GIS unit.

Early workstation GIS combined software capability with expensive hardware and specialist support. ARC/INFO could maintain topology, run overlays and manage large production datasets, while Intergraph systems were used where GIS overlapped engineering, CAD, photogrammetry and high-end graphics. Their cost and complexity concentrated use in organisations able to support trained staff. A workstation on a specialist’s desk was still a long way from GIS being available across a general office.

Desktop products took a different route. MapInfo was designed around personal-computer mapping and business data. ArcView provided a more accessible Esri desktop environment alongside rather than in place of ARC/INFO. GeoMedia later provided another desktop option, and organisations could use several products at once. A 2004 New Zealand study found ArcGIS or ArcView, MapInfo and GeoMedia all present in its sample of councils, universities and Māori organisations, with different organisations choosing different combinations.

The distinction between production and desktop software remained practical. A GIS team might maintain master data in a larger database or specialist environment while other staff used extracts in a desktop package. Some users needed editing and analysis; others mainly needed to view, query and produce maps. A desktop copy could be easier to use without being the authoritative record. New software therefore widened the client end of GIS before it necessarily changed where the master data lived.

That pattern became common across information technology during the 1990s. Central systems did not disappear when PCs arrived. They were increasingly joined by personal tools that allowed staff to work with selected information locally. GIS followed the same path, with the added complication that geographic datasets could be large, coordinate-dependent and easy to copy without carrying all of their context with them.

A clear New Zealand example appeared in Gisborne in the mid-1990s. The East Coast forestry programme had been established to encourage tree planting on erosion-prone land, with grants linked to the area and location of planting. By August 1995 the Ministry of Forestry was using MapInfo to support the programme. A contemporary New Zealand Forestry article described the software being used to prepare maps, tabulate information for grants, show reserves and planted areas, display general land use and calculate the hectares for which payments were due.

The programme involved substantial data-conversion work. More than 16,000 hectares were being monitored under MapInfo by the time of the article. Project manager Randolph Hambling described the system in practical terms rather than as a technology demonstration. The work involved landowners, planting areas and payments, so the GIS had to connect mapped polygons with the records used to administer the scheme. Wellington-based Critchlow Associates was identified as the MapInfo master agent.

Chapter 8 covers the forestry programme itself. Here the case shows what desktop GIS could already do in an operational government setting. The user did not need a national mapping agency’s production environment to draw and measure programme areas, relate them to land use and produce maps for day-to-day administration. The task was bounded enough for a PC-oriented GIS to be useful and substantial enough that the maps were part of programme management rather than presentation.

The East Coast case also shows why desktop GIS spread unevenly. A project with a defined area, known records and a clear set of questions was well suited to a local application. A national cadastral database with millions of parcels had different requirements. The same decade therefore contained both desktop packages used by small teams and large institutional systems maintained on workstations and servers.

Software histories are often written as a neat succession of products. New Zealand practice was less tidy. ARC/INFO did not vanish when ArcView appeared, and MapInfo did not make workstation GIS redundant. Organisations selected platforms according to the work, the data they already held, staff experience, cost and the systems they needed to connect to.

A production GIS might be responsible for editing and quality control while desktop users worked from exported copies. A science organisation could use specialist image-processing software alongside vector GIS. A council could have one package in the central GIS team and another in a business unit. By the early 2000s some organisations had several desktop and server products operating at different layers of the same information environment.

The desktop therefore changed access before it simplified architecture. A staff member could gain the ability to make a thematic map without gaining the ability to maintain the authoritative road network underneath it. A planner could query parcels without becoming a cadastral database administrator. A policy analyst could join census variables to boundaries without running the systems that produced the census geography. GIS work became more distributed even while data stewardship often remained centralised.

This separation became one of the defining characteristics of ordinary organisational GIS. The number of people using spatial information could grow faster than the number of people maintaining it. Desktop tools made that possible because they gave subject specialists enough GIS capability for their own work while leaving the difficult production tasks with dedicated teams.

A Treasury working paper published in 2000 provides a compact desktop-GIS example. Critchlow Associates supplied Census96 data and ArcView software, allowing Treasury researchers to analyse regional economic characteristics without building the statistical geography or a departmental production GIS themselves. The full government-use case belongs in Chapter 24. Here it shows how a policy analyst could receive prepared national data and a desktop tool, then work directly with geographic boundaries and socioeconomic information.

Software plus data

The spread of desktop GIS coincided with a growing market for spatial data on physical media. CD-ROM was particularly useful because it could carry far more information than floppy disks and did not depend on the slow internet connections available to many offices during the 1990s and early 2000s. A supplier could ship software, boundaries, property records or imagery together. The user inserted a disc rather than establishing a connection to the database where the source information was maintained.

That method encouraged products built around particular groups of users. Property professionals needed parcels, titles, ownership and addresses more than they needed a generic GIS environment. Foresters needed stands, roads, terrain and land information. Census analysts needed statistical boundaries and demographic tables. Desktop GIS became more useful when the software arrived with the data required for the job.

Terralink’s TerraView was one example of this packaging. A 2001 National Library record describes a Windows CD-ROM product containing cadastral information sourced from LINZ’s Digital Cadastral Database along with survey-plan references, property and title information and other land records. It required a 100 MHz processor, 32 MB of RAM, Windows 95, 98 or NT and an eight-speed CD-ROM drive. By then a national land-information product could be designed for machines that would have been entirely ordinary in many offices.

The convenience had a built-in date. TerraView’s record notes that the supplied data represented a particular point in time. A CD could be authoritative when it was produced and stale months later. Desktop distribution therefore traded direct connection to the source for convenience, portability and local performance.

QuickMap took the software-and-data model further as a New Zealand-developed product. Custom Software was established in Wellington in 1996. The National Library catalogue records QuickMap Professional from 2002 as a Windows GIS distributed on CD-ROM with cadastral, title, owner and geographic data. Aerial photographs were supplied on accompanying discs.

The recorded system requirements describe the desktop environment clearly. QuickMap could run on a Pentium 133 MHz or better computer with 64 MB of RAM, an SVGA display and about 50 MB of disk space, across several versions of Windows including 95, 98, 2000, NT and XP. Those specifications were modest compared with the specialist workstations that had supported institutional GIS a decade earlier. The product was designed for users who already had a PC for normal office work.

QuickMap also removed the need for the buyer to negotiate several separate data acquisitions before the software became useful. Parcels, titles, owners and geographic data came with the application. A surveyor, valuer, lawyer, property adviser or other user could search and map information relevant to ordinary property work without first constructing a GIS database. The product title described it as a mapping and data-visualisation tool, but the bundle of New Zealand property information was at least as central to its practical value as the map interface.

There is no need to promote QuickMap into a national first. Its value in the history is more straightforward. By the early 2000s New Zealand spatial information could be packaged as a commercial desktop product intended for a broad professional market. GIS capability had moved well beyond the specialist technical organisations that introduced digital mapping in the 1970s and 1980s.

Desktop GIS made spatial data easier to use and easier to duplicate. A central team could export a road network, census boundary layer or parcel dataset and place it on a network share. Staff could copy the file to their own project directories, rename it and pass it to somebody else. Within a short time an organisation could hold several versions of what everyone still called the same dataset.

Maps could make differences in data quality difficult to see. A two-year-old road file could still draw perfectly. Parcel polygons did not announce that a subdivision had occurred after the export. Statistical boundaries could load beside newer census data even when their vintages no longer matched. The visual success of the overlay could give users confidence before they had checked dates, lineage or coordinate information.

Desktop software therefore increased the work around version management and metadata. Organisations needed conventions for storing master datasets, identifying extracts and replacing old copies. Some teams built standard network locations or shared libraries. Others depended on users knowing which file was current. Chapter 21 described the national policy response around metadata and stewardship; on the desktop the same issue appeared as a folder full of plausible-looking files.

Central databases later reduced some of that duplication by allowing multiple clients to connect to the same maintained source. During the desktop expansion, however, the copied file was one of the normal units of GIS work. It was portable, fast and easy to archive with a project. It was also disconnected from whatever happened next in the system that created it.

Desktop GIS lowered costs relative to many earlier specialist systems, but the software still required a budget. A New Zealand study completed in 2004 recorded a single-use ArcView licence at about NZ$3,750 plus GST, with annual maintenance of about NZ$1,200. A concurrent-use licence was recorded at NZ$8,750 plus GST with annual maintenance around NZ$1,800. These figures were observations gathered by the study in November 2004 rather than a universal national tariff.

Training added another cost. The same study recorded introductory two-day vendor courses in the range of roughly a thousand dollars or more. An organisation buying one licence therefore also had to consider support, upgrades and the time required for staff to learn the software. The barrier was lower than purchasing a specialist workstation environment, but it had not disappeared.

The New Zealand supplier network helped organisations cross that barrier. Eagle Technology supported Esri products. Critchlow Associates supplied MapInfo, data and related services. Intergraph Corporation New Zealand supported GeoMedia and the company’s wider product line. These firms provided local training, technical support and implementation assistance as well as software licences.

By 2004 the same study found different patterns across its sample rather than one dominant desktop. Regional councils leaned toward ArcGIS, district councils were more mixed, and Māori organisations in the sample tended toward MapInfo. Environment Waikato was reported as using all three of the main desktop families when required. The finding is a snapshot of the study population, but it captures a market in which GIS users could choose among several established desktop environments.

The Bay of Plenty gives the same period a more personal shape. Stuart Halliday later recorded that he became GIS Team Leader at the Bay of Plenty Regional Council in November 1992 and stayed until July 2003, establishing and implementing the council GIS, writing strategy, supervising three staff and integrating spatial and textual databases. A 2003 national report on New Zealand cartography, to which Halliday contributed, shows that the council did not treat every map-making task as GIS work. In 1998 it created a separate cartography section after deciding that GIS analysis and specialist map production required different skills. CorelDraw, Illustrator and Freehand remained part of the cartographic toolset, supplemented by GIS, CAD and remote-sensing software. Council mapping brought together several specialist systems and working practices.

The desktop market also pushed software formats into routine data exchange. Esri shapefiles became common because they were simple to move between machines and widely supported. MapInfo formats were similarly common in organisations using that software. A supplier wanting to reach both groups often delivered more than one version of the same dataset.

Statistics New Zealand provides a clear government example. By 2007 it was distributing digital geographic boundary data in both Esri shapefile and MapInfo formats. The agency did not need every customer to use the same GIS. It could publish the statistical geography in formats expected by two large groups of desktop users and let them load the boundaries into their existing workflows.

File formats affected how information could be exchanged. Field names, data types, coordinate definitions and attribute structures could change during conversion. Shapefiles carried technical constraints that later formats would address more cleanly. Users still needed to know what had been delivered rather than assume that two files representing the same boundaries were identical in every detail.

Even so, file-based exchange allowed GIS to spread without organisations agreeing on one software platform. A council using MapInfo, a government analyst using ArcView and a consultant using another package could often pass vector data between systems. Chapter 21 described interoperability as a national infrastructure goal. Desktop formats provided one rough, widely used form of it in everyday practice.

A desktop machine could run GIS without being able to handle every GIS task comfortably. Large raster mosaics consumed disk space and memory. National vector layers could be slow to draw or analyse. Complex overlays and topology processing could take long enough that specialist workstations or central processing environments remained preferable. Printing large, high-quality maps still required access to suitable plotters and printers.

Network speed created another constraint. Loading large datasets from a shared drive could be slower than keeping local copies, which encouraged the version problem described earlier. A user might subset a national dataset simply to make it workable on a particular machine. Imagery often had to be tiled, compressed or reduced in resolution. The computer on the desk had made GIS available, not unlimited.

Coordinate systems could also catch less experienced users. Desktop software increasingly automated projection handling, but older datasets were not always labelled correctly and conversion tools could be applied incorrectly. Two layers that appeared near one another on screen could still be based on different datums or source accuracies. Chapter 19 covered the national coordinate transition; desktop GIS put responsibility for recognising those differences into the hands of many more users.

Some organisations therefore retained a mixed architecture for years. Specialist staff managed data and complex processing while desktop users worked with prepared layers. Later enterprise databases and web services would formalise that relationship. During the 1990s and early 2000s it was often held together by network drives, export routines, local conventions and people who knew where the current data lived.

GIS specialists supported the growing number of desktop users. It changed the boundary between specialist and user. Routine map production, simple selections, joins and thematic mapping could increasingly be done by the planner, scientist, policy analyst or property professional who needed the result. The GIS team no longer had to operate every map request as a production job.

That freed specialists for other work while creating a support load of its own. Someone had to prepare standard layers, maintain master datasets, solve projection problems, manage licences, document procedures and help users who had enough software access to get themselves into trouble. Templates, shared symbology, training courses and internal guidance became part of running GIS across an organisation.

Adoption varied. Some organisations kept tight control over GIS licences and data, while others distributed desktop tools broadly. A smaller council might have one person carrying both GIS and other technical responsibilities, while a large department could maintain specialist production teams and dozens of desktop users. Across those different arrangements, more people were interacting directly with spatial information.

By the 2000s, GIS could therefore exist in an organisation at several levels at once. A central database or specialist team maintained authoritative information. Desktop packages allowed analysts and business units to work with it. Commercial suppliers delivered software, prepared datasets and support. File formats and network folders moved information between the layers, sometimes elegantly and sometimes by somebody copying a folder called FINAL into another folder called FINAL2.

Putting GIS on more desks created a new organisational problem. If property staff, planners, engineers, environmental teams and asset managers were all using spatial information, keeping each unit in a separate desktop environment became inefficient. Councils in particular held many datasets tied to the same parcels, roads and assets. The next stage was to connect those uses around maintained corporate data rather than treat each desktop as its own GIS.

That transition had already begun while desktop GIS was spreading. By the mid-1990s local-government adoption was accelerating, driven by planning, property, infrastructure and asset-management requirements. The PC made software accessible to more staff, but councils still needed common identifiers, authoritative databases, update procedures and systems that could serve several departments at once.

That organisational build-out was particularly visible in local government. Councils were no longer deciding only which desktop package to buy. They were linking property, rating, planning, roads, utilities, environmental information and later public access around maintained spatial databases used across the organisation.