GIS made in Canada – Doug Seaborn’s VISION*
Editors note – This Interview was originally published March, 2016 and republished now as it highlights an important and interesting part of Canada’s geospatial history.
An interview with GIS entrepreneur and visionary Douglas W. Seaborn on an exciting period of GIS development in the 1980s and 1990s.
Claus Rinner: Doug, thank you for agreeing to this interview. In 1994, I obtained a coveted student internship position in IBM’s GIS Competence Centre in Bonn, Germany. My job was to run test cases on a new GIS software that was going to supersede their established mainframe-based GFIS. Can you tell me what I was looking at there?
Doug Seaborn: Claus, I’ve been looking forward to re-visiting this time in my career for a while. Most likely you were looking at a prototype IBM version of GeoVision’s VISION* GIS software. We had been marketing and installing VISION* on non-IBM platforms from 1986 to 1991. As best as I recall, our first three installations were in 1987, for Southwestern Bell, the City of Orlando/Orange County, and US West.
Orlando/Orange County was a significant customer for GeoVision, whose aspirations validated GeoVision’s all-relational, enterprise-wide GIS strategy. By 1989, their county-wide database comprised a new geodetic layer and street network driven by nascent GPS technology, 230,000 land parcels digitized from 2,000 map sheets and a new master address database. Early application layers included Land Ownership and Property Assessment, Subdivision Approval and Monitoring, Zoning Code Enforcement, Floodplain Mapping, and Building Permits, and a live interface to their legacy Land/Structures/Occupancy System. Access to city and county employees was assured through 28 high powered graphic workstations and 17 terminals.
Our installations ran on HP, SUN, and DEC workstations and server networks, under the Unix OS. The central “engine” for VISION* was the Oracle RDBMS. IBM approached GeoVision in 1990 to build a version of VISION* for their RISC System 6000 client/server system, using IBM’s RDBMS, DB/2. A prototype version was released to IBM in early 1991, likely this prototype was what you were working with.
CR: What did you do before you founded GeoVision in 1986? When and how did the development VISION* start? What was the role of SHL?
DS: I was one of the founders of SHL Systemhouse, an Ottawa-based systems integration company that, by 1983, had expanded to eight offices and about 700 people. At Systemhouse, I had begun work as a scientific programmer, eventually becoming the project manager for an automated cartography system called AutoMAP. The goal of AutoMAP was to automate the compilation and production of topographic maps at 1:50,000 and 1: 250,000 scales for all of Australia. AutoMAP’s mission was to streamline and enhance map production workflow – from digitizing aerial photographs through computer generation of the offset films driving the colour printing presses. AutoMAP was the first such system in the world and became a big success; AutoMAP ran in production for the Royal Australian Army Survey Corp for ten years.
By 1984, the AutoMAP team had grown into a small mapping systems business unit in Systemhouse, and had branched into software for hydrographic charting, forestry, land use, and even modeling and mapping ice flow movements in the Canadian arctic. SHL lost interest in the mapping business. I felt it had potential, so in 1984 I made an agreement with Rod Bryden, SHL’s CEO at the time, to gather the nine employees, isolate the group from SHL in less expensive quarters, and to re-brand the company as GeoVision.
CR: I remember that my internship manager and colleagues were really excited to work with a modern GIS software. An important part of that was that the new system was “object-oriented”. What does that mean?
DS: At that time, object-orientation was attracting attention in the software world. It meant different things in different application domains, but primarily it meant a new architecture that separated data and code. We certainly did design, build and market a dramatically different software architecture for a GIS system: VISION* stored geographically-referenced data [“geo-data”] in complete harmony with traditional textual or alphanumeric data in a SQL database.
At that time, other GIS software generally treated geo-data separately from other data. Their systems used their own proprietary database and query language for the geo-data; the non-spatial data separately stored in dBase or Info. These systems had a fundamental problem ensuring database consistency between the spatial and non-spatial realms, and were not able to scale with respect to numbers of concurrent users or size of database. Given their proprietary spatial databases, the usefulness of those systems seldom reached beyond the department which had acquired it. For other departments to participate, these departments had to wait for the vendor to develop and provide applications to address their departmental needs, and likely acquire their own minicomputer to support their new users.
At GeoVision, our idea was that a standard commercial RDBMS should become the custodian of all of the customer’s infrastructure, asset, and service data – both spatial and non-spatial. We decided to store the (x,y) ground coordinate stream of each geographic entity or object, the object’s tabular or textual attributes and any images [scanned drawings or photographs] specific to the object – in the RDBMS. Of course, we had to develop and store bi-directional spatial search indexing schemes [in our case, quad trees] in the relational tables too. This was not a simple task, but it was worth it. For our customers, the payoff was huge: they could use Oracle’s published APIs and development tools – just as our software engineers did – to develop geo-centric applications beyond those that GeoVision could offer them at the time.
In parallel with our “all-relational” software development, we took advantage of an exciting confluence of new hardware and OS technology. By 1984, SUN, DEC, and HP had all begun to offer client/server architectures. We convinced Oracle to make versions of their RDBMS product available on SUN, DEC, and HP servers. We made sure much of the VISION* visualization processing used computing resources in each user’s workstation. To do this we introduced map tiling which distributed load across the customer’s network. As a result, we became the only GIS vendor whose system could scale to hundreds of concurrent users. Our largest telecom customers (e.g. US West) were able to support over a thousand concurrent designers operating with a data-base containing tens of millions of telephone infrastructure objects located across fourteen states. Also bear in mind that ten years later, Oracle began to build spatial and other capabilities first commercialized in VISION* into Oracle. This ultimately became Oracle Spatial.
The third and final advantage was that we promoted the VISION* geodatabase to be managed by the customer’s IT department. Our view was that the infrastructure database was mission-critical to our customers, therefore it should be managed and cared for by IT experts, not by engineers, planners or management staff who would otherwise be required to learn and do IT tasks. Our end user departments – say engineering, planning, public works, land information – did not have the skills or experience to manage and safeguard their database. For example, database backup, performance optimization and tuning, failure recovery or off-site security. Our competitors were primarily urban planning, geography, or engineering graduates who had learned programming, but had no idea of robust, industrial-strength IT practices, nor how to go about incorporating them in their software. In VISION*, for each of these tasks, Oracle provided the tools for the IT department, who took care of everything for them. VISION* user departments could then simply focus on their job which was to retrieve common, shared, enterprise-wide data (such as base maps) from the common enterprise database, then build their own data layers on top. If user departments needed applications development, they had several choices; they could contract with GeoVision or with a third party system integrator or solutions vendor who could do application development using Oracle’s extensive development tools.
To answer your question, Claus, my recollection is that our VISION* branding included terms like, “all relational GIS” and “enterprise-wide GIS.” I think it was a British company, Smallworld, who invented the term ”object-oriented GIS” a few years later. By late 1992, GeoVision had won “enterprise-wide” customers and installations across the USA, Canada, Australia, New Zealand, France, and the United Kingdom. IBM had become a major investor in GeoVision and our software engineers were busy building a version of VISION* for their RISC System 6000 hardware, using IBM’s AIX as the operating system and DB/2 as the SQL geodatabase engine.
CR: Was GeoVision connected with Canadian or American universities at the time? Was there knowledge transfer or influence one way or the other?
DS: Some of our fundamental structures and algorithms were contributed by outside researchers. At the time, our main competitor was ESRI, which had focused its applications in land use, natural resources, local government, and the education market. Technically we felt that a natural match and differentiator for our system’s capabilities were engineering workflow applications, which had to scale to millions of infrastructure items and hundreds of users, and maintain data integrity.
So, GeoVision redirected its market focus to infrastructure geodatabases for utilities (electric, gas, water) and telecom companies. The utility infrastructure/outside plant market was nascent at the time, led by IBM [with an ageing mainframe-based offering – GFIS], Intergraph, and Synercom. It was clear we had to learn, then lead this new market on our own terms. In responding to this market, one of our key innovations was data versioning (also called long transactions) for spatial objects. This was beyond the capabilities of other GIS products including Intergraph and ESRI at the time, and gave us another technical advantage in addition to data consistency and scalability in a very technically demanding application.
CR: Despite its qualities, VISION* is not around anymore. What led to its demise? Are there lessons to be learned for today’s GIS software industry or for the open-source GIS community?
DS: Yes, Claus, you are right, VISION* is no longer actively marketed, but VISION* is still running, supporting hundreds of concurrent network designers at several large infrastructure companies. The company and product line was acquired by Autodesk, in 1999. Autodesk continued to support existing customers, but decided not to continue active development of the product.
As noted, IBM had taken a significant equity position in VISION* because it was deemed strategic to their interests at the time. In the early 1990s, however, IBM’s interest in GIS underwent a major and rapid change, which left VISION* in a very difficult operating situation. This resulted in GeoVision going into receivership.
Many talented and remarkable people – far too many to mention – made significant contributions to the development and success of GeoVision and VISION* over the years. I’m especially grateful to Richard Higgins and Geoff Zeiss, who took over the VISION* mission from my leadership in late 1993, engaged many GeoVision employees in a successor company SHL VISION* Solutions, and attracted another 50 or so enterprise class accounts around the world by 1998. I had no role in this exciting re-birth and renewal of VISION*. However, I was extremely pleased that the talented engineers who worked with me to create VISION* got to realize and enjoy its pre-eminence in the global enterprise GIS market. Richard and Geoff kindly guided me with some background facts to this interview.
CR: After VISION*, you pursued several other careers and visions. Can you tell me about those?
DS: After losing GeoVision, I did GIS consulting under contract for a while for customers including BC Hydro, Manitoba Hydro, Portland Gas & Electric. In 1995, I saw an opportunity and co-founded a company with a very different mission: develop and market a software product to assist pediatric cardiologists in the detection, assessment and monitoring of congenial heart disease in children. Eight years later our company, VMI Medical was successful in attracting 22 of the leading Children’s Heart Centers across the USA. I enjoyed the work immensely: at last, a software offering that offered and helped realize true benefits to children, to their parents, and to their care providers. But health care is a “high touch, close to the customer” market. By 2005 VMI had become too large and distant to be headquartered in Ottawa; I faced moving the company to a USA market like Boston, or sell it. I chose the latter. VMI ended up in a new home at Camtronics Medical Systems, later Merge Healthcare [ironically, now a part of IBM], in Wisconsin, USA. I then worked with Camtronics as an Account manager for their Adult Heart Centers a couple of years before returning to Canada.
CR: When you contacted me about taking our Master of Spatial Analysis (MSA) program, and I saw your CV, I was surprised. You must be the most over-qualified MSA student ever! What piqued your interest in going back to school, and what are you hoping to get out of the MSA?
DS: I became a software engineer after graduating in math and physics, one who imagined a few application ideas. Thanks to my Dad, I acquired the imagination, persuasiveness, and persistence to propagate and commercialize some of my ideas into emerging or nascent markets.
In the ten years after VMI Medical, 2005 to 2015, my technical credentials and skills had become stale. I was no longer knowledgeable, skilled or confident in the applications and technology of today’s web-centric and mobile-facing software driving today’s large spatially-enabled databases. I realized in March 2015 I had to go back to school, re-learn the new technologies, tools and applications of GIS.
In yet another moment of serendipity, I met your colleague Phil Coppack on a bike ride in May 2015. Phil he told me about your Master of Spatial Analysis program. By then, U of T had accepted me for a Master’s in Computer Science. But, after one month in the MSA program, I discontinued student life at U of T and decided to invest all my learning time in Ryerson. I thank you for admitting me; it’s been a great decision for me.
CR: Geospatial technology and GIS concepts and tools are a staple of the Department of Geography and Environmental Studies at Ryerson, with our BA in Geographic Analysis colloquially known as the “GIS program”. Nevertheless, most students and faculty are GIS users rather than developers. How do you see the role of coding in Geography, and the relationship between GIS software and the real-world problems it helps solving?
DS: Claus, my feeling is that I’ll have sounder insight into this question later in your program. For now, my imperative is to learn to use and apply contemporary GIS software – for example ArcMap, Intergraph, MapInfo, Alteryx, Maptitude, QGIS – to real world applications that, as MSA students, we are required to solve and deliver in our assignments.
I expect some of our assignments here at Ryerson will stretch packaged applications beyond their capabilities. Each of us will have to learn some coding – for instance Python or Java – to achieve the results and marks we strive for. However, my inclination is to push packaged applications as far as one can, or simply go find more of them. Chances are someone has already written the tools needed; with the miracle of the internet we can find most of what we need somewhere in proprietary or open source format.
I was never a great programmer; to me coding is somewhat tedious. I’d rather produce a 90% solution for my customer quickly with available tools; you won’t find me investing much time in coding. Like in a classic trade-off between bespoke versus packaged off-the-shelf software, I’m inclined to use what’s already available.
CR: Ryerson University puts great emphasis on innovation and student entrepreneurship. Can we expect you, as an MSA student, to create the Next Big Thing in Ryerson’s Digital Media Zone?
DS: At this early stage in the MSA program, yet late stage in my career, I must say I don’t know. I’ve been fascinated with maps and geography since my canoe tripping days as a young boy. With today’s resources – mobile computing and communications, crowd-sourcing, GPS, and large spatial databases like OpenStreetMap – my excitement grows every year. I can tell you that I will try to bring my experience and interests in GIS towards contributing more innovations.
The prowess, skills, and focus of the 22 students in my class impress me more and more every day. The spatial discovery projects they dream up are interesting, challenging, and break new ground. I’m thrilled to work with them and be part of the MSA program.
CR: Doug, thank you so much for taking the time and I look forward to follow-up conversations about R&D in GIS and Geography.
Wow. A piece of GIS history I did not know! I wish GeoVision was still around and part of the GIS marketplace today.
It just goes to show that frequently style and marketing will triumph over substance and capability.
I was on the team that worked to develop VISION* for the City of Calgary, indeed, I was one of the votes for a slender majority that picked GeoVision over ESRI in 1990. (ESRI was the bigger company and should have won – did win, about 1997, when we switched to them. GeoVision won for two reasons: Canadian patriotism, and that all-relational storage approach. ESRI was still storing the coordinates in proprietary files and having to synch the database to them.)
The product taught me GIS, how it works under the hood, because their whole Oracle database – which also held the coordinates. I would say it was a mistake to push that GeoVision allowed you to manage everything with the IT department, because it Calgary, it soon became clear that the Engineers could learn GIS tables and software usage much faster than the IT department could understand the complex GIS needs of multiple departments.
VISION* ultimately was tossed by Calgary because it couldn’t draft – it’s “Builder” module for marking up maps was unusable as a CAD tool, we couldn’t build water/sewer/streets drafting departments around it any more than Microsoft Paint. Alas, ESRI was not much better, and I wound up inventing a quasi-GIS – not for map display, just for drafting – with our CAD tool, Microstation. The IT department was so fixated on drafting with ESRI that they wouldn’t permit us to have “write” accounts on the GIS servers, so I wrote it to store the coordinates in simple numerical columns instead, and make Microstation map files from the Oracle-stored coordinates, which IT then loaded into ESRI with FME conversion tools.
This works poorly (17-hour copy once per week) but it has worked, for over 15 years, and the CAD-based GIS drafting tool – which writes to a database that looks remarkably like the VISION* database from 1990 – is still how 35 draftsmen do all of Calgary’s water and sewer systems drafting. I retired five years back, and it’s still running today.
I used to work at GeoVision in the early 90s after doing two work terms with them. Was a really great development team and enjoyed being a part of it.