Front page   Table of Contents   Abstract
Chapters  1   2   3   4   5   6   7   8   9   Bibliography

Chapter 8: Prototype Development: a Digital Orthophoto Browser for the Boston area

1. Introduction

The preceding chapters (4-7) examined several geographic information infrastructures being built to link the activities of government agencies. This provided insights into the role of today’s state of the art technologies in these agencies, and into the complexity and uncertainty surrounding the growth and implementation of such systems in such a context.

Whereas the preceding chapters focused on the complexities of inter-organizational context, this chapter adopts a very different angle on geographic information infrastructures. It reports on a year-long software development project, conducted within the broader United States National Spatial Data Infrastructure, and aimed at building tools for enhanced network dissemination of digital orthophotos. The project’s outcome, an interactive browser interface to digital orthophotos for the Boston area, embodies several design principles outlined earlier for loosely-coupled sharing of information. In particular, it embodies a data services model for information sharing, it provides several kinds of access to these services, and it employs metadata to facilitate networked data discovery and interoperability between software systems.

The project is a useful contribution to the discussion of geographic information infrastructures (whether national, or regional as in the case studies) in that it surfaces, first, several key tradeoffs in building the needed packages of technology. It also gauges, in a very tangible way, the impacts that may arise from assembling existing and emerging network technologies in new ways. Third, by examining the technological side of infrastructures in some depth, and by considering the role of emerging network tools, the project provides a useful counterpoint to the organizational case studies, and extrapolates their conclusions into the near future within a changing technological context.

The following sections summarize, first, the goals of the US National Spatial Data Infrastructure (NSDI) and how this project was to contribute to them. This is followed by a sketch of the project’s specific goals and development stages; the functions provided by the final product; and possible implications of the project for the NSDI and the three case-study contexts.

2. The National Spatial Data Infrastructure and the orthophoto browser

a. National Spatial Data Infrastructure overview

The orthophoto browser is in part an outcome of several years of activity in state and federal governments in the area of geographic data sharing and standards. In late 1990, the US Office of Management and Budget established the Federal Geographic Data Committee (FGDC) with a mandate to promote and coordinate digital mapping activities throughout the country (OMB, 1990). One of the FGDC’s key objectives has been to build a National Spatial Data Infrastructure: this was proposed by the Mapping Science Committee of the National Research Council (1993) and established by a presidential Executive Order (EOP, 1994). The NSDI is described as "an umbrella of policies, standards, and procedures under which organizations and technologies interact to foster more efficient use, management, and production of geospatial data" (Tosta and Domaratz, 1997). NSDI development is along three principal objectives:

The National Geospatial Data Clearinghouse. The Clearinghouse is a decentralized network of Internet sites that provide metadata describing available geographic information. Subsequent to the Executive Order, the FGDC adopted the Z39.50 standard and developed a metadata Content Standard (FGDC, 1994) for search and retrieval functions in the Clearinghouse. (The Executive Order also calls on federal agencies to "draw up a plan" for distributing geographic information itself to the public; but Clearinghouse efforts thus far have remained focused on metadata.)

Standards to facilitate the sharing of geospatial data. These standards are established through broad consultation with state, local, and tribal governments and the private and academic sectors. Standards to date have included the Content Standard for Geospatial Metadata (FGDC, 1994) and the Spatial Data Transfer Standard (NIST, 1992).

The National Digital Geospatial Data Framework. The Framework is a set of the most commonly-used layers of geographic information, including transportation, hydrology, political boundaries, and digital orthophotos. Responsibility for collecting and maintaining these data layers is shared among state and local agencies in a given region (FGDC, 1995).

Underlying these three primary thrusts, the FGDC has emphasized training programs and inter-agency partnerships, in recognition of the importance of decentralized approaches to maintaining detailed geographic information (Tosta, 1994). To promote participation in the first of these objectives, the Clearinghouse, in 1994 the FGDC established a Competitive Cooperative Agreements Program (CCAP), a series of small "seed money" grants to state and local partnerships to assist them in setting up Clearinghouse nodes with FGDC-compliant metadata and Z39.50 Internet access.

b. Relation of the orthophoto browser project to the NSDI

The orthophoto prototype was developed with funding from the FGDC’s Competitive Cooperative Agreements Program (CCAP). The project was devised to meet FGDC Clearinghouse requirements by providing standardized metadata on orthophotos via the Z39.50 protocol. In addition, it used the orthophoto service as a test-bed to experiment with alternative ways to

provide networked access to the orthophotos and metadata by a broad class of users;

distribute the orthophotos efficiently over a limited network bandwidth; and

link the networked orthophoto service more tightly with client GIS software.

These additional objectives were a response to likely futures of the National Geospatial Data Clearinghouse. First, as the Clearinghouse goes beyond delivering metadata and begins to serve large datasets, efficient and manageable network access will require query mechanisms for retrieving portions of a dataset according to geographic coordinates, resolution, and other criteria. By using image data, this project afforded a chance to begin exploring the distribution of large geographic datasets without the burden of complex or proprietary data structures. Second, to use Clearinghouse information effectively, users will often need to compare, complete, or otherwise combine it with their own information resources. This motivated the development of new forms of inter-communication between navigational Web browsers and analytical GIS viewers. Third, to foster the distributed, "organic" growth of the Clearinghouse as data providers put suitable information online, the orthophoto service was designed to be easily managed and replicated at other sites.

The project’s intent was to contribute not only to the Clearinghouse effort itself, but also to inform the design and development of the NSDI’s networked standards and of its Framework distribution mechanisms. As such, alongside detailed metadata, the orthophoto project provided digital orthophoto data, reusable, configurable tools for networked access to orthophotos, and insights into future NSDI development strategies in a networked context.

3. Design goals and development stages

a. Background and design goals

Digital orthophotos are useful for a wide variety of purposes, given that they combine the visual richness of a photograph with the geometric qualities of a map. This makes them useful both as backdrops to traditional line maps (zoning, transportation, etc.) in geographic information systems (GIS), and as clearly intelligible representations of geographic space for a broad audience.

However, orthophotos are usually large enough (tens to hundreds of Megabytes apiece) to exclude all but specialist, dedicated users. They require generous amounts of storage space, powerful tools to extract and rescale image portions for particular uses, and GIS expertise to position the image correctly behind a map—not to mention the challenge of choosing among hundreds of very similar files, or of pinpointing which portion of an image covers a given location. Thus, despite the advent of CD-ROMs, fast processors, and improved mapping tools, effective use of orthophotos remains time-consuming and tedious—too much so for ad hoc use in many smaller government agencies and among a broad "non-specialist" audience. Putting these orthophotos on a networked server is attractive in that it would alleviate the burden of data storage and maintenance for these users. However, it would introduce limitations due to network bandwidth; and users would still need to choose orthophotos for a given location, create image excerpts of a practical size, and integrate them into a digital map. Therefore, this research effort focused on building server-side tools to facilitate finding and retrieving only the image portions needed, compressing them for efficient use of a limited bandwidth, and providing the header files as needed to integrate the image portion into GIS maps.

The orthophoto prototype also served as a pilot study for MassGIS, the GIS data center for the state of Massachusetts, which had begun to compile a statewide orthophoto series (some 2,000 grayscale images at 0.5 meter resolution, totaling 120 GB) and was exploring networked options for disseminating these to state and local agencies and the public.

Finally, I designed the project so as to test some of the ideas I’d been developing in my research on geographic information sharing. I wanted to balance the organizational understanding of geographic information infrastructures with an in-depth view of the technical components involved, their interconnection, and their interdependence.

b. Development stages

I developed the orthophoto prototype in collaboration with Joseph Ferreira, Jr., the project’s Principal Investigator, and Thomas Grayson of MIT. I initially worked with Thomas Grayson on building metadata; he then focused on metadata search strategies, and I was principal architect for the graphical browser and server tools. Christian Jacqz and Carl Nylen at MassGIS provided orthophotos and documentation on CD-ROMs, and related technical support. Between early 1996 and early 1997, the MIT team built metadata files, processed the orthophotos, and performed all software development using the facilities of the Computer Resource Laboratory in MIT’s Department of Urban Studies and Planning. The next several paragraphs (i-v) describe the stages in the development of the orthophoto browser; more details on the resulting product may be found in Section 4 below.

i. FGDC-compliant metadata for pilot orthophotos; begin manipulating images
This involved, first, learning the intricacies of the FGDC metadata standard. Early attempts to reduce it to a relational database form (for dual use as plain text display and searchable index) proved unsuccessful, and plain ASCII text became its canonical form. Verifying the metadata’s accuracy also required repeated checking with MassGIS staff, reading photogrammetric project reports, etc. Simultaneously with this metadata work, MassGIS delivered its first set of (4) orthophotos, and I began experimenting with a freeware suite of graphics utilities known as pbmplus, to gauge their usefulness and performance for manipulating the large images in the MassGIS series.
ii. Preliminary Web-based interface to (tiled) orthophoto excerpts
At this point, designing the interactive browser’s interface was my primary concern, and raised several questions about what capabilities to expect of the clients, what kind of networking would link the clients to the server, what users and uses to support, and how much server-side processing we could afford. These questions illustrate well the challenges that separate simply putting data online from providing a widely useful infrastructure for sharing geographic information, so it’s worth spelling them out in some detail.

First, the HTTP and HTML standards, understood by any Web browser, provided good uniformity across a wide range of client software and hardware. (This uniformity has enabled many information services to be built in recent years that would otherwise have reached only a small audience.) However, because newer HTML elements might not be understood by all Web browsers, a frequent tension existed between providing useful features and including a wide audience. The varying capabilities of GIS systems provoked a similar tension when it came to integrating the browser with client-side GIS software. What to expect of client software was the subject of many lengthy conversations on the project team, and indeed the answers shifted considerably even within the project’s time-frame.

As for networking capabilities, an important challenge was to use the network sparingly. Much of the Internet user base, circa 1996, had modem-quality access (14.4 to 28.8 kbits/s; magazines joked about "the World Wide Wait"). To include a broad audience, it was important to send files of modest size, compressed wherever possible. Yet a growing portion of the audience did have high-bandwidth connectivity; and some important uses required large image sizes and highest-quality (uncompressed) images.

Third, although the project was clearly tied to geography and GIS by its funding and personnel, its intent was to extend the use of orthophoto data to a much wider audience (while still giving the GIS audience something worth their while). This raised another set of questions for the orthophoto interface: how well should the user know geography concepts, or the Boston-area geography? How would people find their way around the orthophotos? (For instance, would they know that the Charles River runs horizontally across the screen, separating Boston from Cambridge?) How to provide enough geographical information (coordinates, scale, etc.) for GIS users, without complicating the interface too much for the typical "Web surfer"? These questions, too, were the subject of many conversations.

Finally, several server-specific questions arose. For instance, given the quasi-continuous geographic space represented by the orthophotos, users should be able to choose excerpts in literally millions of locations and sizes—far more than could be prepared in advance. So, some (computationally costly) server-side image processing seemed necessary; yet response times needed to be low, a few seconds at most, for the browser to be properly interactive. So, how much real-time processing could the server afford to do in serving up these orthophotos? The answer depended on a combination of hardware performance and software efficiency. Multi-user access was another consideration: how many queries could the server handle at once before reaching memory or disk-space limits, or slowing down unacceptably? Managing the orthophoto service brought another set of questions. Any pre-processing of the images reduced the need to process them on-the-fly; but how many files, or how complex a data structure, were we willing to maintain? A good bit of trial-and-error was needed to resolve these questions.

Together, all these questions made the prototype effort much more than building something to suit a specification. Rather, the requirements were uncertain and changing, and choices along any of the above lines could "make or break" the usefulness of the data service. In particular, for this next phase of the project, because initial tests of the pbmplus utilities showed less-than-satisfactory performance on anything but the smallest images, I chose to defer all server-side image processing for later in the project. Instead, in April 1996 I built the first prototype around fixed, prefabricated image tiles (Figure 8-1), even though this would clearly limit the user’s flexibility in navigating around the orthophotos, and would impose a significant file-management burden on the server.
 

Figure 8-1. Preliminary "tiled images
For this preliminary version of the browser, each orthophoto was pre-processed as follows: (i) cut each 8,000×8,000 pixel image into sixteen 2,000×2,000 excerpts; (ii) cut each of these into sixteen 500×500 tiles (Figure 8-1), storing these in compressed (JPEG) form; (iii) rescale the 8,000×8,000 and 2,000×2,000 images by a factor of 16 and 4, respectively, and store these in compressed form. This resulted in a series of 500×500 compressed image tiles, at three zoom levels, for each orthophoto. A script running on the server kept track of all these tiles: in response to a Web user’s requests to zoom in and out, or to go north, south, east, or west, the script would select the tile that best fit the desired area, and present it as a "viewport" within an HTML page similar to Figure 8-5 below. Although each 8,000×8,000 master image is about 61 Mbytes, the compressed tiles displayed in the viewport were in the 80 kByte range, thus accessible even over dial-up.
iii. Build a final orthophoto browser interface with custom image "snippets" and GIS headers
This preliminary interface was a convenient entrée into the images; its performance was entirely adequate on a Digital DECstation 5000; and it did use the network sparingly. But its fixed tiling scheme did not allow users to position their viewport very precisely, or to resize it to suit a variety of needs. Also, maintaining 273 (1+16+162) separate files for each orthophoto was an unacceptable maintenance burden on the server, especially when it came to including more image formats and tenfold more orthophotos. Furthermore, I found that I could obtain greatly improved performance in the pbmplus image-extraction utility (called pnmcut) through a small source-code change. So for this next stage, I looked into extracting images as needed from a single large master image.

In the initial "tiled" design of the orthophoto browser, the server-side script simply chose which one of many pre-existing image tiles to present to the user. For the second-generation orthophoto browser, the goal was to extract sub-images on the fly from a single 8,000×8,000-pixel master image for each orthophoto. This would allow users to position their viewport precisely, to set its size as large or small as they wished, and to choose any zoom level for viewing the images. It would also greatly simplify management of image files on the server. Finally, through in-line format translators, multiple image formats could be distributed from the same master image.

This required two server operations to be done on the fly: extracting a portion of a large master image, and rescaling the extract to a requested size. In July 1996, I modified the browser’s script to call the newly streamlined pnmcut, and to "pipe" its output through a (JPEG) image compressor before displaying it in the viewport. (Details in Section 4 below.) Each request now created a new image excerpt, instead of just choosing a pre-existing tile: so users could zoom in or out on a precise spot, re-center the map on a precise location, and size the viewport as needed. This image excerpt was not stored anywhere on the server, but was piped to the user as a stream of bytes preceded by an image header. By simply inserting various image-format translators into the pipe, it also became possible to serve up the same image-excerpt in a variety of formats, all extracted on the fly from a few large master images.

I had hoped to use another pbmplus utility, called pnmscale, to rescale image excerpts on the fly. Combined with the pnmcut utility above, this would have given the user a continuous set of zoom levels, all extracted from a single 8,000×8,000 image. However, rescaling images is a by nature a compute-intensive process, and the pnmscale utility reflected this in its slow performance. To maintain acceptable response times, therefore, my fallback was to maintain three master files for each orthophoto: one at each of three fixed zoom levels (8,000×8,000, 2,000×2,000, and 500×500). This provided somewhat jarring jumps (1:4 or 4:1) when zooming in or out; but it maintained good performance, and the file-management burden was still quite acceptable (only 3 files, instead of 273, for each orthophoto; the two rescaled versions only occupied 7% additional disk space).

I used the same "piped" approach to provide the geographic header files needed to incorporate each image excerpt into a desktop GIS package on the client machine. The resulting interface is shown in Figures 8-5 and 8-6 below.

Of course, all this interactive functionality required the server to do much more work than before in response to each of the user’s mouse-clicks. To ensure continued rapid response with many simultaneous users, in August 1996 we moved the orthophoto service from the DECstation 5000 to a dual-processor Sun Microsystems SPARCserver 1000E, tuned for fast computation and network data services. Interestingly, the "piped" server-side processing introduced no delay in the response time (the client starts receiving bytes immediately); instead it limited the output rate to about 90 kBytes/s. This is about half of T1 bandwidth (1.544 Mbits/s), still faster than most Internet lines, as of mid-1997. (In other words, in most cases, the server still has to wait for the client to catch up, not the other way around.) As typical bandwidths increase in coming years, however, this could become a bottleneck and may require faster hardware or software, different compression schemes, or smart caching on the client or server.

Finally, I made a small change to the script, whereby parameters specifying the image excerpt appeared in the URL used to call the script (previously these parameters were "posted" invisibly to the script). This allowed users to bookmark particular orthophoto views in their browsers for future reference, and to embed the dynamically created images into their own Web pages. These images would not be stored anywhere (client or server); rather, displaying such a page onscreen would trigger the orthophoto browser script via the Web. As run-of-the-mill software tools become more integrated with Web services, these dynamically-generated images may well find their way into online documents, spreadsheets, or digital maps. This would free the orthophoto service from the confines of a Web browser, and weave it into all kinds of everyday work.

iv. Unveil full-scale service to a wide audience; examine management and replication issues.
 
 
As the second-generation orthophoto browser was nearing completion, additional MassGIS orthophotos became available, ultimately reaching a total of 118 orthophotos (7 GB, with an additional 500 MB for the two rescaled versions of each orthophoto). This prompted the design of scripts which kept the data-maintenance effort manageable. In late September 1996, we announced the orthophoto service on a variety of email lists: its use quickly grew to about 14,000 "hits" per day, and has persisted at about 1,500 hits per day, from a broad cross-section of Internet users (Figures 8-2 and 8-3).

Figure 2. Internet subdomains using the orthophoto browser, Sept. 1996-March 1997
Figure 3. Orthophoto browser usage, Sept. 1996-March 1997
I then focused on the replication of the orthophoto browser at other sites. First, by assembling a similar browser interface for color orthophotos of the Washington, DC area, I confirmed that the scripts I’d written could be fairly easily adapted to other orthophoto series. Also, in keeping with its decentralized nature, the NSDI Clearinghouse seemed most likely to grow in an "organic" fashion, as Internet-accessible sites learned to become Clearinghouse nodes. To this end, I wrote a tutorial documenting the various components of the orthophoto service, and explaining how to set them up for orthophotos at other sites.
v. Discussion of development stages
These stages of development are more than just a "war story": they illustrate a more general set of tradeoffs to be balanced in designing components of geographic information infrastructures, given that available GIS and networking technologies are in rapid transition. First, despite an otherwise sound design, server and network performance can make or break a given strategy. For instance, the new design in stage 3 above wasn’t feasible without a few changes to the pnmcut image-processing utility. Also, moving to a fast server and using image-compression schemes allowed useful interactivity in the final version of the browser: without them, the browser would have remained an interesting novelty, but too slow for any practical use. Second, these stages illustrate the multiplicity of answers as to how software systems can interact, or what capabilities can be counted on when designing either GIS systems or networked data services. For instance, a primary thrust of this project was designing an interactive HTML interface; but as future GIS software provides increased network integration, the orthophoto service will probably be expected to handle a variety of geographic queries. These and other choices took into account current technological conditions (circa 1996), and they may or may not continue to make sense as these conditions inevitably change. This highlights the importance of building systems like this one in a modular, or "layered," fashion, so that components can be swapped in or out as needed; also, if these components are already available then a project like this one can focus its efforts on "bundling" them in creative and flexible ways rather than building them from scratch.

4. Product functionality

The final orthophoto prototype, accessible at the URL <http://ortho.mit.edu> (Figure 8-4), provides simple interactive access to digital orthophotos. Four aspects of the prototype distinguish it from more conventional approaches to distributing geographic information: its interactive geographical interface, its links to client-side GIS software tools, its dynamic creation of custom data products from a single set of master data, and its links between the data and searchable metadata. It also helps to bridge the barrier of geographic scale by providing a detailed geo-referenced "canvas" for creating line (vector) maps of many kinds. This makes it a promising example of the style of technology needed to build practical, high-impact infrastructures for geographic information.

a. Browser overview
 

The image browser, depicted in Figure 8-5, is the primary access point for most users. It displays a viewport showing a portion of an orthophoto, with controls that allow the user to pan across an image and to adjacent images and to zoom in or out on the image. Each time the user requests a new view, the server extracts a custom image from a master image, and sends it to the user in compressed (JPEG) form for viewing. At the top of the browser page are buttons that link to the project’s main page, to metadata on this image, and to imagery overviews. The viewport is oriented with North pointing up, and a dynamic scalebar tracks the scale at each zoom level. (Not shown in the figure are controls for resizing the viewport, from postage-stamp size to more than full-screen.)


In another part of the interface (Figure 8-6), the viewport image can be downloaded in several file formats (GIF, GeoTIFF, TIFF, and JPEG) and resolution levels (½ , 2, and 8 meter pixels). To prevent abuse of the service, image file sizes are estimated in advance, and requests that exceed a (fairly generous) limit are denied. Users can also obtain geographic header files for the image, so as to overlay it with digital maps using GIS software such as ArcView® or MapInfo®.
 

Behind the interface is a script on the server (draw-ortho.cgi), written in the perl language (Wall et al., 1996), that receives parameters from the user via the HTTP Common Gateway Interface (CGI). These parameters are embedded in a lengthy URL like the following:

http://ortho.mit.edu/nsdi/draw-ortho.cgi?action=zoomin&dwidth=600 &dheight=400&x=252&y=189&image=237898&width=400&height=300 &middlex=250&middley=250&zoom_level=4
The parameters include, first, an "action" to be performed ("zoom in," "pan," "go north," etc.), along with the desired viewport size and where needed, the coordinates of the user’s mouse-click. These are followed by several state variables passed between client and server, that keep track of the current image name, viewport size and coordinates, and zoom level.

Based on these variables, the draw-ortho.cgi script computes the coordinates of a new image excerpt, and then calls another script (stdout.cgi) which runs several software utilities in the pbmplus freeware suite to extract the sub-image from the full master image, reformat it to the desired image format, and pass it back to the user via Unix’s "standard output" byte-stream.

Two more scripts (mi-header.cgi, av-header.cgi), when activated by the user, compute the geographic location of the image and return it as a header file formatted for MapInfo or ArcView.

b. Links to metadata

Each image accessible through the orthophoto browser is associated with a set of metadata elements that describe the image according to long list of criteria set forth in the Federal Geographic Data Committee’s (FGDC) Metadata Content Standard. This is useful in two ways: first, while looking at an image in the orthophoto browser, a user can click on the "FGDC Metadata" button (cf. Figure 8-5) to review the author, date, precision, and processing history (etc.) of the image. Second, before perusing the images graphically, users can find out which ones to look at by querying the orthophoto metadata as a library catalog. This is done through a simple form interface which lets users search on keywords in specific fields (place, author, etc.), as well as on location (a latitude-longitude bounding box) or the date of data capture or publication. The forms interface is shown below:
 
Figure 8-7. Metadata: keyword search
 
Figure 8-8. Metadata: spatial and temporal search
For instance, a user searching for images covering the North End (a neighborhood in Boston) can request that string in the "Place-Keyword" field. Upon receiving this query, the server returns a set of "titles," hypertext links to the images in question. The user can click on one of these links to see the full set of metadata—of which one element is a hypertext link to the image itself, viewed through the orthophoto browser.

Besides this interface, these metadata are also accessible to any networked client via the Internet’s Z39.50 protocol (Kahle, 1991). Because they also conform to the FGDC’s Content Standard, users can search this and many other metadata sites simultaneously to find and review items of interest regardless of their location on the network.

The collection of standard-content metadata accessible via the Z39.50 protocol is known as the National Geospatial Data Clearinghouse, which users query through multi-site search services like that at the FGDC’s Clearinghouse Web site (www.fgdc.gov). The FGDC’s query form is identical to the one at ortho.mit.edu, but with an additional section, shown in Figure 8-9, for multi-site searches. Through this form and others like it, the Clearinghouse lets users find the orthophoto browser without knowing in advance its address or even its existence.

5. Evaluation

The orthophoto prototype can be evaluated in several ways: its fulfillment of the CCAP project terms, its demonstrated value to researchers, reports of its use, and its performance along the yardsticks set forth for the cases.

a. Fulfillment of project objectives

First, the orthophoto browser fulfilled the terms of the FGDC project by providing a Clearinghouse node with Z39.50 searchable metadata on the orthophotos. It also provided access to the orthophotos themselves, with reusable tools for others to replicate similar services elsewhere. A final report is in progress.

b. Demonstrated value to the research community

Second, the prototype provided opportunities to reflect on how emerging technologies, or current tools assembled in new ways, can impact geographic information sharing. The prototype has already led to several invited conference presentations as well, including GIS/LIS, Auto Carto, and the New England and Pacific Northwest Chapters of URISA.

c. Usage reports

Another way of evaluating the prototype is a purely pragmatic one: Was it useful? The charts in Figure 8-2 and 8-3 tell part of the story, but another measure of its usefulness came in the form of anecdotes, mostly by electronic mail. In Boston’s Public Facilities Department, a data manager finds that the orthophotos provide quick, easily understood views of building footprints, vacancies, and vegetation patterns in various urban neighborhoods: these are useful at community meetings in conveying the scope and impact of the City’s plans. At the Boston Redevelopment Authority, members of the research department use the orthophotos to correct and update their existing street maps: the pictures help them to realign their street lines more precisely and to weed out lines that correspond only to rights-of-way through existing blocks or parcels. In November, 1996, someone from Boston City Hall (ci.boston.ma.us) downloaded the entire collection of orthophotos at the intermediate zoom level (2m pixels), leaving behind noticeable spikes on the charts in Figures 8-2 and 8-3 above. We also received comments from GIS and other researchers and educators, mapping firms, students, a major logging company, federal and state agencies, and many others.

d. Performance along the case-study criteria

One last way of evaluating the orthophoto prototype is to use the same criteria as those used in the case studies. As before, this evaluation is in two parts: the user’s perspective, focused on the data being shared and its use, and the architect’s perspective, focused on maintaining and growing the mechanisms of information sharing.

First, the timeliness and concurrency of the prototype are based on the update frequency of the orthophotos (every few years at best) and the rate of change of the urban landscape they represent. The locational precision of the images (0.5m pixels) and their accuracy (90% of pixels less than 2.5 m off) are enough to suit a wide range of mapping purposes, such as the Boston Redevelopment Authority’s use of them as a backdrop "canvas" for geo-referencing vector maps. The semantic precision and accuracy of the images are related to their radiometric resolution (here, 220 different shades of gray) as well as factors such as cloud cover or sun and shadow angles. Unlike conventional vector maps or tabular databases, the individual pixels contain no meaning as to land use, hydrology, or roads—let alone property lines or state boundaries. However, visual interpretation of the patterns of light and dark easily fills in semantic content. The precision or accuracy of this visual interpretation varies widely across the image: for instance, water bodies are easily identified by their dark color, but a grassy field may have nearly the same grayscale luminance as an asphalt road. Here again, this is enough detail for the two example uses: it enables people at community meetings to see clearly what lies behind the lines of a property or zoning map; and it provides a clear view of even the smallest city blocks for maintainers of street files. Finally, the browser scores high on the encapsulation criterion, given that it puts image data files into any of several common file formats and also prepares the necessary header files for loading the images into GIS/mapping packages.

Second, taking the "architect’s" view, reciprocity is one area in which the orthophoto prototype does not score very high. As a one-way data distribution mechanism, it provides only informal mechanisms (such as unstructured electronic mail) for "upstream" data sharing. An interesting extension to such a browser would be a facility for users to send their own orthophotos or maps for display in the browser viewport—or even to send lists of coordinates or street addresses for others to overlay them atop the orthophotos. The HTML ENCTYPE tag may be helpful in providing this capability in a future version. Next, scalability is one criterion along which the orthophoto browser measures up rather well. It withstands the load of several thousand data requests per day with no noticeable delays; its open access accommodates any client host; it runs on a single server at present, but its different tasks could be easily split among several (e.g. one just for images, or even one for each type of image). Finally, by producing images and header files in multiple formats, the prototype attains a high degree of non-intrusiveness by accommodating, from a single dataset, a variety of user requirements. Furthermore, it doesn’t impose free and open access: the prototype restricts access based on file size, but any number of restrictions are possible, based on time-of-day, client domain, image quality, server load level, etc. The service could be restricted to subscriber sites, or could even charge users pennies per transaction.

6. Implications: what’s different about the orthophoto browser?

What does the orthophoto bring to those who will build the National Spatial Data Infrastructure? To the agencies I observed in my case studies? To other, similar contexts? To answer these questions, I will first summarize what’s different about the orthophoto browser compared with more usual methods for sharing geographic information.

By instantiating many of the technical recommendations arising from the case studies, the orthophoto browser shows what different technological choices may be brought to bear. In particular, it provides a widely accessible "just-in-time" geographic data service, it supports access through metadata, it enables interoperability between different software systems, and it suggests promising directions towards scale-free geographic referencing.

a. A widely accessible, "just-in-time" data service

Unlike more conventional mechanisms for sharing information that rely on putting fixed data files online, the orthophoto prototype prepares custom data products as needed. (Note that this required tuning the components of the server, to account for a wide range of client software and network connectivity.) This alone could play a key role in facilitating the integration of data maintenance and electronic distribution in the case-study contexts. First, thanks to the orthophoto browser’s "just-in-time" architecture, maintaining the orthophotos for both internal and external use remains easy, with no proliferation of temporary files or multiple uncoordinated copies of the same data. Second, access methods are appropriate for a wide variety of users: novices and GIS experts alike, whether in the next room or across the Internet, can get to the data they need quickly, with little need for assistance. Compared with a conventional online archive such as an ftp server, or a data center selling preset or special-order bundles of images on CD-ROMs, the orthophoto browser requires a lot less work on the part of either the data provider or the user to make the data useful. Third, the data can be corrected or updated even after the service is launched, so careful documentation of information may impose less of a delay. In summary, the prototype turns a large dataset into an easily used, low-maintenance data service. Gateways like this one could do much to merge the often separate activities of internal data management and external data distribution as seen in the cases, as well as the dichotomy between expert and novice uses.

b. Information integration through metadata

This service addresses the need for metadata to search for and interpret geographic information in a few simple ways: it provides header files for incorporating the images into several GIS software systems; and it provides a full FGDC metadata listing, which can be searched via the Z39.50 protocol, or reviewed in detail to determine the fitness of the orthophotos for a particular use. The metadata’s standard content also offers the promise of direct interaction between the orthophoto service and future client-side software systems.

c. Interoperability between software systems

Third, the prototype helps to shift the focus of geographic information sharing from compatibility between datasets to interoperability between software systems. It does this in several ways: embed orthophoto URLs into other Web pages (and, soon, documents, spreadsheets, and maps); the Z39.50 protocol which lets users query the orthophoto metadata simultaneously with other such services across the network; and the provision for several different client-side GIS systems. Several additional kinds of interoperability could be built: the ability to specify locations by latitude and longitude or even by street address; and, more generally, a standard language for querying the orthophoto server. As such, the prototype heralds the unbundling of today’s large software applications into a networked "fabric" of independent but interoperable data services. This of course has organizational ramifications, which will be explored further in the next chapter.

d. Towards a scale-free referencing system

Finally, the Pacific Northwest’s experience with River Reach files in particular highlights the challenges of building a consistent geographic reference system, and then evolving it to suit increasingly demanding needs and an increasingly complex set of technology choices. The choice in that case was to store properties of the river network as a table of properties tied to river reaches, and cross-reference these river-reach codes to those in the various states. A newer approach to this problem, based on "dynamic segmentation," stores "events" tied to a linear "river mile" referencing system and computed their geographic locations only when displaying them on a map. However, the same river may measure twice as long at a 1:24,000 scale as it does at 1:100,000. Thus, upgrading an event table to a more detailed map scale is not an easy process: it requires computing geographic startpoint and endpoint coordinates for events using the less detailed river features, and then (through a variety of geographic approximations) building a new event table for use with the more detailed streams.

Putting easy access to orthophotos at everyone’s fingertips may offer a more accurate alternative: if field workers were to use highly precise orthophotos as a backdrop to enter observations and measurements, their "events" could be tagged with geographic coordinates (e.g. latitude/longitude), rather than linear coordinates, and they would be less dependent on a particular map representation. As the need for geographic detail and precision grows, it wouldn’t be hard to swap in more precise orthophotos where needed; or conversely to keep only low-resolution ones in areas with few features of interest. This approach may not be completely scale-free (the pixels do have some size); but by providing precise locations instead of scale-dependent feature geometry, significant gains in precision and accuracy may be possible. The orthophoto browser isn’t the last word on the issue; rather it highlights ways in which a few improvements in technology and system performance can make a continuing problem marginally easier to address.

7. Implications for the National Spatial Data Infrastructure

Due to its unique features, the orthophoto prototype suggests several useful directions for the National Spatial Data Infrastructure (NSDI)’s strategies: it explores ways to grow the NSDI Clearinghouse into a source for integrated geographic data and metadata; it shifts the NSDI standards focus onto software interfaces and query languages, and it shows how networked access to digital orthophotos might play an important role in the NSDI’s Framework.

a. Growing the NSDI Clearinghouse beyond metadata

The orthophoto browser shows how the Clearinghouse might grow to provide both geographic data and metadata in an integrated fashion. Its detailed, standardized metadata allows users to evaluate the image data and its appropriateness for their use; also, users trying to locate relevant geographic data for a project can also search this site in parallel with other metadata sites. Metadata records also link directly to the orthophotos themselves, within a multi-purpose interface. Of course, one key reason for the Clearinghouse’s focus on metadata is that not everyone wants to give away their geographic data files: this prototype’s very simple mechanism for access control (based on file size), suggests any number of mechanisms for restricting access to certain sites or users, allowing only sample access, or requiring lump-sum or per-byte payments.

b. Shifting the focus of NSDI standards

By preparing images and header files in a variety of formats, the orthophoto browser begins to delve into the larger problem of GIS interoperability. Greater integration with client-side GIS tools would require two kinds of standards: a commonly accepted way of specifying geographic queries, and a way to send queries from these tools to a Web browser or Web server. Although it’s possible to create special-purpose software to integrate a few special cases (such as one or two different GIS packages), more general solutions await agreed-upon standards for specifying geographic data entities and requests. Whereas many standards efforts thus far have emphasized data standards such as file formats, the orthophoto prototype’s small foray into interoperability suggests that functional standards, such as query languages and software interfaces, may recast the NSDI as a link among heterogeneous geographic software components.

c. Networked orthophoto services in the NSDI Framework

Finally, the prototype’s use of high-resolution raster data provides a novel form of geo-referencing, allowing users to enrich their maps visually and to update their line datasets. This in itself is an important contribution to the NSDI Framework; but in addition, this prototype suggests that the Framework may consist not just of data files but of active data services that can prepare custom data products for each user and function within a limited network bandwidth.

8. Implications in the case-study contexts

a. More-than-incremental change

Finally, a key finding from the cases was the difficulty in moving from a temporary "scaffolding" to a more long-term distributed infrastructure. On both the technological and organizational fronts, this may require forgoing incremental changes in favor of more radical changes: that is, "leapfrogging" to completely new ways of doing things instead of building on what’s known. Compared with conventional vector GIS, or indeed tabular databases, the highly precise geographic referencing provided by these orthophotos opens up completely new ways to tie information from many different sources to spatial locations within a single map. Furthermore, the move to networked services in information sharing may effect radical shifts in the management of information systems, from guarding a comprehensive set of data and software applications, to finding reliable sources of information and processing services and forging interoperable links to these sources. Some will prefer a more secure data management plan, where an organization maintains all the information it counts on for its work. And especially in the area of geographic information, reliable, interoperable data services are still very few in number. So before these radical, non-incremental changes can occur, functional standards may need to take hold to support interoperability, and unbundled geographic processing services may need to become more widespread and reliable. So despite the need for non-incremental change expressed above, organizational change and technology may need to evolve in parallel and thus more incrementally. Chapter 9 explores standards, services, and change patterns in more depth.

b. Who pays? Distributing responsibilities, costs, and benefits

Finally, one implicit theme underlies the case studies: "why bother building infrastructures to share information"? The costs of building infrastructure systems are usually immediately tangible, considerable, and unevenly distributed. Yet their benefits are often distant and uncertain, and often accrue to many more users than those that paid for their development. The next chapter discusses a variety of ways to resolve these tensions, either through government intervention (subsidies, seed money, standards) or by providing some return on investment (fees, prestige, barter, etc.). Related to this is the need to share the data maintenance responsibilities in a reliable fashion among many players.

In short, the orthophoto prototype provided a concrete setting for surfacing the interplay of technological and organizational aspects of building relevant spatial data infrastructures. Whereas the case studies of Chapters 4-7 shaped views of what choices are worth making in technological design, the prototype experience helped to interpret the case experience and ways of extrapolating issues towards the future. Chapter 9 explores these issues in greater detail, as they apply to technology choices, organizational structures, and policy priorities most conducive to building effective geographic information infrastructures.


 Front page   Table of Contents   Abstract
Chapters  1   2   3   4   5   6   7   8   9   Bibliography