Early web mapping

GIS reaches the browser

At the end of the 1990s, a geographic information system could still be a very literal place. In New Zealand Police, the early analyst GIS was installed on customised workstations at individual sites. Crime and mapping data were loaded locally, printers were part of the setup, and different installations could drift into different software versions. The system did useful analytical work, but every additional site brought another bundle of installation, maintenance and support. This was a manageable model while GIS remained a specialist activity used by a relatively small number of trained staff.

The browser changed that equation. Instead of placing a complete GIS application and its data on every user’s machine, an organisation could keep much more of the application, processing and information centrally and allow people to reach selected functions through an ordinary web browser. The user still needed a computer and a network connection, while the organisation still needed servers, databases, software, administrators, security and support. The complexity moved. More of it could be managed once, centrally, rather than reproduced across many local installations.

Desktop GIS remained essential for specialist analysts who needed to edit data, design maps, build models and ask questions beyond a pre-built browser application. Browser GIS solved a different problem. It allowed a much larger group of people to search, inspect, query and display geographic information without becoming full GIS operators. By the early 2000s policing, public health, councils and central government used browser GIS alongside specialist desktop systems.

The documented early New Zealand web maps were interactive information services delivered through websites. They were interfaces to maintained information systems. Behind the browser sat operational databases, spatial layers, business records, servers and staff responsible for keeping the whole arrangement working. The screen could look simple because the difficult work had moved elsewhere.

GUILD-on-the-Web, 1996

Landcare Research was delivering environmental spatial data through the web by January 1996. GUILD-on-the-Web was developed under Robert Gibb’s leadership, with David Medyckyj-Scott as a co-developer. Medyckyj-Scott’s published author biography dates its release to January 1996 and places it among the earliest online GIS services. Their 1996 paper described the application at the University of Otago’s Spatial Information Research Centre colloquium. GUILD gave public users a browser interface to environmental information held by the research organisation.

Medyckyj-Scott recalls GUILD as a possible first operational web service created specifically for public access to environmental spatial data. His 2016 paper with Andrew Cowie also described it as the first environmental-data web-mapping site. Those are participants’ assessments of its place internationally. The January 1996 release establishes an early New Zealand example before the health and council applications described later in this chapter. GUILD also provided a conceptual predecessor to Landcare Research’s later data portals and browser mapping services.

The experience travelled with Medyckyj-Scott to the United Kingdom. He joined the University of Edinburgh’s Data Library in 1997 and led work on Digimap, which became an EDINA service for higher education. After trials in six university map collections, Digimap launched on 10 January 2000, providing Ordnance Survey maps and downloadable digital data. Medyckyj-Scott identifies GUILD as the conceptual background for that work. He recalls Digimap reaching hundreds of universities and about 100,000 registered users by his departure in 2010.

PHEW! in 1999

Public health was an early use of browser-based GIS in New Zealand. In 1999 the Ministry of Health began combining GIS and the Internet to present communicable-disease information through the Public Health Early Warning system, known as PHEW!. When the New Zealand Public Health Observatory was launched in May 2002, the Ministry described PHEW! as allowing anyone with a web browser to create and view maps, tables and statistics from the national notifiable-disease surveillance system. The Ministry described it as a world first.

PHEW! sat on top of a wider public-health information environment. EpiSurv held notifiable-disease information, address geocoding converted reported cases into mappable locations, and territorial boundaries and population data allowed patterns to be displayed and compared. Contemporary research described PHEW! as exposing a subset of EpiSurv information at Territorial Local Authority scale. The service widened access to information prepared within the epidemiological system. A person could reach nationally maintained health information through a browser without running the analytical GIS used to prepare and manage it.

Government descriptions, academic references and historic URLs describe PHEW!’s functions. Its original browser interface, scripts and server configuration have not survived in the available archives. Early web applications depended on servers, browser components and database connections that were often replaced without preserving a working copy.

PHEW! was already treating the map as a generated view of current information rather than as a finished paper product. A user selected information, the system returned a map or table, and the same underlying records could support another view. The browser made the relationship between geographic information and the map used to display it more flexible than it had been in a printed workflow.

A map without GIS software

Early browser GIS was attractive because the browser was ordinary. By the turn of the century it was already present on routine office computers, and users knew the basic conventions of links, forms, buttons and pages. An organisation could therefore provide a constrained geographic application without asking every user to learn the full interface and file structure of a desktop GIS. A person looking for an address, a property, a disease pattern or an operational location could be given only the tools required for that task.

The trade-off was deliberate. Browser applications usually offered fewer analytical and editing functions than specialist desktop software. A guided query might be easier to use precisely because the application designer had already decided which layers, fields, searches and outputs were relevant. This reduced training requirements and made support more predictable, but it also limited the questions a user could ask. Early browser GIS widened reach by narrowing freedom.

The technology reinforced that pattern. In many first-generation systems, data and most spatial processing remained on the server. The user sent a request, and the server returned a map image or a small amount of query information. Interfaces could be slower and more brittle than later web maps, especially over modest network connections. There were no assumptions of modern vector tiles, cloud-native services or rich JavaScript clients. The browser was a thin window into a centrally operated system.

This architecture also made maintenance more organisational. Updating the map service, changing a data connection or adding a standard query could be done centrally instead of repeated across dozens of workstations. The GIS team did not disappear. Its role shifted towards maintaining a service used by people who might never know which GIS software was behind the page.

James Maguire’s 1999 Massey University thesis records another approach to widening GIS access. Working with Genasys New Zealand software, he developed a Java viewing client with vector, image-download and database components. The project addressed the performance and usability of tools available to occasional GIS users. It places client-side GIS development within the late-1990s New Zealand software record, alongside the server-based web systems used by public agencies.

Police moves to thin client

New Zealand Police used browser mapping to make geographic information available to more staff. The early-1999 client GIS was initially distributed to nineteen analyst sites and later expanded to thirty-three. Each site carried the cost and support burden of a customised workstation, printer, local software and locally loaded mapping and crime data. Once the organisation wanted broader access, this architecture became cumbersome.

About eighteen months after the desktop rollout, Police decided to replace the locally installed application with web-based mapping as part of a wider thin-client strategy. Wellington used the MAPS name by November 1999; a general browser-based release followed in late 2000. The two dates mark distinct stages in that move to web mapping.

Routine mapping could potentially be reached from ordinary networked Police computers rather than from a small number of specialist installations. Intelligence analysts remained the main users, but guided queries and simpler mapping functions could be placed in front of operational staff as well. The practitioner history described a system connected to national intelligence and dispatch information, bringing mapping closer to the organisation’s current records rather than relying on occasional local data loads.

Specialists continued using desktop GIS. Police later retained or restored higher-end analytical capability for users who needed more flexibility than the browser application provided. This coexistence is central to the period. Web GIS expanded the audience while desktop GIS remained the workbench for specialist analysis, data management and system administration.

Census geography on the web

Statistics New Zealand’s 2001 Census products show another version of the transition. In March 2002 the department documented a free public Census WebMap on its website. Browser users could identify geographic areas and obtain Census statistics without owning specialist GIS software. MapData Sciences was commissioned to develop and host the service.

WebMap was free to view; access to the underlying GIS data had separate conditions. The same March 2002 product sheet priced the complete Meshblock Database at $1,200 plus GST and multi-organisation use at $5,000 plus GST. Digital boundaries were supplied under licensing arrangements, while authorised suppliers sold mapping packages that combined Census information, boundaries, topographic overlays and software. A person could therefore look at statistical geography for nothing while an organisation wanting to reuse the same geography in its own GIS still faced charges and licence conditions.

Browser access and open data arrived through separate changes. Browser access lowered the cost of seeing and querying information. Open licensing and reusable downloads changed the terms on which people could obtain the data itself. Two months later, in May 2002, the Government announced free access to detailed Census results through the Census Table Builder, explicitly identifying cost as an access barrier. Open-data policy and services continued to develop after this release.

The Census WebMap also demonstrated something broader about public institutions. A web map could publish a carefully selected view without distributing the organisation’s entire analytical environment. Statistics New Zealand could control which geography, statistics and functions appeared in the service while keeping the underlying production systems separate. The browser was becoming a publication layer over institutional GIS.

Public access without open data

That separation between viewing and reuse appeared elsewhere. A council could display parcels, rates information or aerial photography while still restricting bulk access to some underlying datasets. A public-health site could show aggregated disease patterns without exposing individual records. An internal government portal could make operational layers available to staff while keeping them off the public Internet. Web GIS allowed organisations to widen access selectively.

This selectivity was also part of information governance. Once maps moved beyond specialist staff, organisations had to decide which attributes could be shown, what scale of information was appropriate, how frequently the data should be refreshed and what disclaimers were required. Public users also needed an interface that reduced the chance of misreading technical information as a definitive legal or operational record.

The browser created a new publishing responsibility for GIS teams. A desktop analyst could be assumed to understand some of a dataset’s limits; a member of the public could not. Help pages, explanatory notes and warnings became part of the spatial service. Dunedin WebMap’s help pages explained cadastral limitations, rating relationships, aerial-photo alignment and why some information appeared only at particular scales.

The same pattern would become normal in later public data portals, but in the early 2000s it was still being worked out application by application. The first web maps were teaching organisations how to become publishers of interactive geographic information.

The map leaves the counter

Upper Hutt City Council’s XPLORER provides a well-documented early example of a council public viewer. Before the online service, the process was simple but inconvenient: visit the council and ask for a paper “property packet”. That was especially awkward in a city where a large proportion of residents worked elsewhere and had to fit council visits around working hours. The council wanted property and rates information to be available without requiring a trip to the counter. The web map was therefore solving an ordinary civic nuisance as much as a technical GIS problem.

From February 2003, council-held property information was available online through XPLORER. The service included land information and aerial photography. A United Nations e-government case study later reported about 26,000 map downloads a month and described reduced in-person enquiries as staff directed users towards the website. Residents were obtaining council information online instead of visiting the office.

XPLORER turned part of the council’s information service into self-service. A resident could locate a property and inspect selected information directly instead of relying on staff to assemble and explain a paper packet. The council still had to maintain the records, the spatial data and the application, but part of the search work moved to the user. The map became part of service delivery.

By early 2003, Upper Hutt’s public web GIS was handling enough enquiries to change routine customer contact.

WebMap inside the council

Browser GIS was also spreading internally before every service became public. Christchurch City Council’s 2001/02 planning material linked GIS and Webmap development with property and environmental information inside a wider electronic-information programme. By February 2003 the council reported that the corporate Webmap rollout had been completed, user numbers were up 35 per cent from June 2002, and the number of available datasets had grown from fifty-five to sixty-nine.

Those figures describe a different audience from Upper Hutt. Christchurch’s Webmap was primarily an organisational distribution mechanism. Staff who did not need full desktop GIS could still reach common property, environmental and spatial information through the corporate environment. The web browser allowed the council to make its spatial investment useful to many more employees than the specialist GIS team alone.

This also changed where the work of GIS specialists was concentrated. Instead of producing every map request directly, the team increasingly maintained authoritative datasets, symbology, database connections, map services and application behaviour. The number of visible GIS operators could remain small while the number of people consuming their work increased sharply. Users could work through a simple interface while GIS handled the data and processing behind it.

Other organisations followed a similar approach. National organisations faced the same problem at a larger geographic scale. If centralised spatial information was going to support remote offices, the delivery model had to work on ordinary computers and imperfect networks.

ArcIMS inside government

The Department of Conservation documented its national enterprise GIS in 2003. The department’s National Enterprise GIS used ArcSDE, ArcGIS and ArcIMS, with DOCgis acting as a browser-oriented access layer over national spatial and business information. A technical paper from 2003 records an ArcIMS HTML application serving eight-bit PNG map images, stored queries, national geodatabase layers and access to non-spatial databases. DOCgis Intranet and Extranet Version 2.0 were scheduled for June 2003, while a Java client version was planned for August. ArcSDE, SQL Server and the national geodatabase carried central data, while specialist staff continued to use desktop GIS.

DOCgis Release II gave conservation staff a centrally hosted browser interface, including those at remote offices with older computers and dial-up connections. Its selected mapping tools made national spatial information reachable across a dispersed organisation with the network capacity available at the time.

DOCgis also demonstrates why server-side rendering was attractive. If the server performed much of the processing and returned a map image, the local computer did not have to carry the full dataset or the full GIS application. The browser became a practical endpoint for staff who needed to inspect and query national information but did not need to maintain the underlying spatial database. Centralisation made wider distribution possible.

The enterprise model also exposed a new dependency. If many staff relied on the same central service, the reliability of the server, network and data update processes became more important. A local desktop application might fail for one analyst. A national browser service could fail for everyone. Wider access raised the operational stakes for GIS infrastructure.

Dunedin WebMap

Dunedin City Council’s WebMap help pages show how early public web GIS behaved. Built with Esri ArcIMS, the application generated simple maps on request and connected them to the Rating Information Database, addresses, cadastral parcels, aerial photography and other council information. The pages describe address, road and place searches, property identification, rate-account links, scale-dependent display and user-selected map types.

The help material also preserves the awkwardness of the period. Users were warned to keep a second council browser window open because the rates pages and WebMap depended on one another. Resizing the map window could cause the map to disappear. Some functions could fail if browser scripts entered an erroneous state, requiring users to close windows, clear the browser cache and start again. Popup blockers could interfere with printing. Some early web-GIS skill was therefore less about spatial analysis than knowing which window to leave alone and when to clear the cache. Interactive mapping had arrived with plenty of friction.

The documentation was equally careful about the information itself. Parcel boundaries were described as cadastral land parcels rather than rate-account boundaries, aerial photography could contain positional error, and some rural or older survey boundaries were less reliable. Cadastral data from Land Information New Zealand were updated periodically, then stated as every one to two months. Aerial photography carried its own copyright conditions. The help page treated data provenance and interpretation as part of the application.

By April 2004 Dunedin City Council was documenting WebMap for public users. The guides brought browser instructions and explanations of the council’s data together for that audience.

Browser limitations

The first web maps were powerful because they were limited. A council resident did not need to edit parcels or run network analysis. A public-health user did not need access to individual disease records. A conservation manager did not need every ArcGIS tool simply to inspect a national layer. A Police operational user did not need the full analytical environment used by an intelligence specialist. Applications could be designed around these narrower needs.

Those limits also protected the organisation. A controlled browser interface reduced the risk of accidental editing, constrained access to sensitive information and standardised how common queries were performed. It could also simplify training. A user learned the application’s tasks rather than a general GIS package with hundreds of commands. This was one reason web GIS spread so readily inside organisations once server infrastructure was available.

The cost was flexibility. If the application did not contain a required query, layer or analytical function, the ordinary user could not improvise. Specialist staff were still needed to answer unusual questions, maintain the datasets and change the application. Browser GIS therefore did not flatten the profession. It created a layered relationship between system builders, analysts and a much larger population of consumers.

Performance was another constraint. Early services had to work across comparatively slow networks, modest desktop computers and browsers that were less standardised than later ones. Server-generated map images reduced demands on the client but could require a round trip for each pan, zoom or query. Interfaces were often functional rather than elegant. These applications helped organisations provide mapping services to staff and the public.

Mapping services

By 2003 and 2004, the underlying pattern was visible across several sectors. Police used browser delivery to reduce distributed workstation maintenance and expand internal access. PHEW! made national public-health information available through maps, tables and statistics. Statistics New Zealand provided a free browser window onto Census geography while separately managing reusable data products. Councils were using Webmaps both as corporate information tools and as public self-service. DOC was treating browser mapping as part of a national enterprise architecture.

The organisation maintained data and processing behind the interface. Users requested a map, search result or answer tied to a place.

This changed what counted as a GIS user. The browser user might never digitise a polygon, choose a projection, design a map layout or administer a database. They might not even know the organisation considered the application part of its GIS. They simply needed property information, disease statistics, an operational location or a conservation layer. Geographic information was becoming useful to people who did not need to join the GIS profession described in the previous chapter.

The shift also made the map less self-contained. A browser map was temporary, generated from maintained systems and capable of changing as the underlying records changed. It was no longer the final authoritative object in the same way as a printed map sheet. Increasingly, the authoritative investment sat behind the screen in databases, identifiers, update processes and services.

Keeping it current

The move to browser delivery also made update cycles visible in a new way. A printed map could carry a publication date and remain unchanged until a new edition appeared. A web map looked current because it was online, even when some of its layers were refreshed only periodically. That appearance created a risk: users could assume that an interactive service reflected the latest authoritative record simply because the page responded immediately.

Early systems handled freshness in different ways. Police wanted intelligence and dispatch information to reach operational mapping quickly, while council cadastral layers could be refreshed on a much slower cycle. Dunedin’s help material explicitly told users that LINZ parcel data were updated periodically, then described as every one to two months. The distinction between a responsive application and current source data had to be explained. The browser could generate a map instantly from information that was still weeks old.

Centralisation nevertheless gave organisations a better way to control updates. A revised dataset placed behind a centrally managed service could become available to all users without distributing replacement files to every workstation. This reduced one form of version drift, although it increased dependence on disciplined publishing processes. The organisation needed to know which copy was authoritative, when it had been loaded, which services consumed it and whether a failed update had left users looking at stale information.

The same issue affected public trust. A property viewer, health map or operational application could appear authoritative because it came from a government or council website. That made provenance, caveats and update notes part of the cartography. The web map was an interactive application whose controls changed what information the user could retrieve and display. It was a promise, sometimes implicit, about where the information came from and how much confidence the user should place in it.

Digital evidence disappears

The early browser period has left a peculiar historical record. DOCgis survives unusually well because a training guide and a detailed technical paper were retained. Dunedin’s help pages still expose the vocabulary, browser problems and data warnings of an early ArcIMS application. PHEW! is almost the reverse: its purpose, date and functions are securely documented, but the original visual interface remains missing.

The applications depended on software and infrastructure that changed over time. Interactive web systems were assembled from several moving parts: a page, scripts, GIS services, databases, authentication, network addresses and browser behaviour. Preserving the HTML alone might preserve only a shell. A web archive could capture the surrounding page while the map service itself vanished. An application that served thousands of users could therefore leave less visible evidence than a paper map printed in a few hundred copies.

For the history of digital mapping, manuals and help pages become unusually important objects. A screenshot can show the controls a user actually saw. A training guide can reveal the intended workflow and the assumptions made about the user’s computer. A technical architecture diagram can identify which part of the system performed the work. Even an error message or instruction to clear the browser cache can locate the application in a particular technological moment more accurately than a later summary saying only that a council had “online GIS”.

Early browser GIS depended on the software, data, service configuration and institutional support behind its visible interface. Preserving a working map meant maintaining those parts together.

The audience is about to change

By the middle of the 2000s, browser GIS was no longer an isolated experiment inside New Zealand organisations. The difficult institutional questions had already appeared: where authoritative data should live, how services would be maintained, what information could be published, how slow networks would be handled, what a non-specialist user needed, and how public viewing differed from data reuse. These questions had been confronted before mass-market web mapping became familiar.

Then the wider web began to change expectations. In September 2006 Google announced geocoding support for Australia and New Zealand, allowing New Zealand street addresses to be converted to coordinates for use in Google Maps and web applications. By then the public was beginning to encounter maps that panned smoothly, searched addresses and appeared as ordinary parts of consumer websites. Institutional web GIS had prepared New Zealand organisations for browser delivery, but consumer mapping was about to make the audience much larger and much less patient with awkward interfaces.

The next stage widened access to existing web-mapping functions. It changed the standard against which web maps were judged. The early systems described here had already separated geographic information from the specialist workstation and placed it behind ordinary browsers. Google Maps and Google Earth would make that experience commonplace.

The first web maps therefore sit between two eras. They were built from the databases, GIS software and institutional systems of the 1990s, but they pointed towards a world in which location would be expected everywhere. Their interfaces have often vanished, and some now look crude in surviving documentation, yet the organisational change they introduced has endured. GIS became more centralised in architecture and more distributed in use, and the map became an interface to a service rather than the end product of the system.