As of 22 April 2009 this website is 'frozen' in time — see the current IFLA websites
This old website and all of its content will stay on as archive – http://archive.ifla.org
As of 22 April 2009 this website is 'frozen' in time — see the current IFLA websites
This old website and all of its content will stay on as archive – http://archive.ifla.org
The Map and Geographic Information Center at the University of Connecticut is the primary map collection and geographic reference center for the State of Connecticut. As such it serves the business community of Connecticut. Connecticut is the insurance, pharmaceutical and submarine and jet engine center of the USA. The information needs range from historical maps and aerial photography to cont emporary computer mapping and statistical analysis. Particular interest will be paid to business use of on-line resources.
As part of the Federal Depository Program, the government distributed copies of the TIGER Line Files on CD to over 1400 libraries around the country. These CDs have been made available to the general user community in a variety of ways. Today, I will talk about how these data and other digital geo-spatial data has been provided at my library, the Map and Geographic Information Center (MAGIC) at the University of Connecticut’s Homer Babbidge Library.
MAGIC is established on the foundations of building collections of spatial material, describing that material for the research community, and providing access to the user community. These three functions define MAGIC and, I think, begin to describe virtual map libraries. The role of the map librarian becomes more function and less task based as the map librarian becomes a more focused knowledge -based worker. Our pre-occupation with the collection gives way to providing spatial information, regardless even, of whether it is cartographic based.
This grant funded the development of an on-line spatial information system which provided census mapping of Connecticut by town and census tract. As the grant was implemented, it became apparent that with the type and amount of data being dealt with, the PC needed to be linked to a mainframe computer. Remember, cutting edge technology in 1987 was an XT with 254 Mb of RAM, 80 Mb of harddrive and an EGA monitor. The DIME tract polygons, as SAS data sets, were acquired from Geographic Data Technology. These came on 9 track magnetic tape. The only access to the data was through a tape mount on the mainframe, the only place to store the data was on an OS disk on the mainframe, and the most appropriate software was SAS, SAS/AF and SAS/Graph. In addition, the grant was to map census data w hich was available in SAS format. Networking became a given.
Mapping of census data had been going on for a while. What the LSCA grant brought to the process was a librarian. When confronted with which data to map, the problem emerged as a collection development issue. Given all of the demographic data available, which data sets were the most used As a collection development issue the problem was one of who is the user, reference or research? My defi nition of a reference user at the University of Connecticut is an undergraduate who wants an 8 1/2" x 11" map for a five page paper and doesn't want to spend more than 30 minutes making it. A research user is writing 6+ pages and/or working on an on-going project and has "all the time in the world." The grant was developed for the reference user. Of the demographic data available, those variables chosen for the Urban Atlas series were selected.
Digital cartographic data available for Connecticut by town and tract was selected. User profiles are important for developing strong, focused collections.
The major work of the grant was to build a user interface. We used SAS/AF to build the menu. Writing menus is hard work. It forces the librarian to deconstruct the reference interview. Discussions with other map librarians helped to deconstruct the general map reference questions. As a profession we need to begin to think more about this in a formal way. It has implications in artificial int elligence and intelligent interfaces. Our strength lies in our ability to serve the unsophisticated user. The spatial reference interview may be our biggest contribution to society. It empowers us as librarians to recognize that we are the interface to spatial information.
In 1989 that XT was the only computer in the map library. Though it was important for the user to come in and use it in the library, if all the data were on that machine, only one person could use the data at a time. The networked mainframe allowed PTOLEMY to be accessed in the Geography Lab as well as the library. It was set up as an account that others could "attach" to. The power of multi-u se, multi-access, multiplace is awesome, it has the ability to put spatial data resources on the scholar's workstation, as well as in the library.
The research user was not to be denied. When they found that PTOLEMY had streamlined access to the data, they became the largest users. But they began to use the data, both demographic and cartographic, without the interface. They began to access it directly off the OS disk and write their programs accordingly. They only needed to know where it was and where a data dictionary that described th e variables could be found.
I expect that a fair amount of our time will be spent providing telephone support, providing on-line support and building tools for these users. Having MAGIC up on the campus LAN has given me pause to consider what the map librarian's role should be. One way to think of the user is as either GIS literate or GIS illiterate. Another is to think of the use to which the client is putting the spati al information; reference or research, for example.
Literateness is a measure of one's ability to read and write or decode and encode information. Working with digital data, one's ability to decode or encode goes hand-in-glove with computer hardware and software. Without the computer the information is on a disk or is a harsh squawk on the end of a telephone line. With the computer, but no software, the information is observable as text if it is ASCII, or gibberish if it is compiled data. But, with appropriate hardware and software the information becomes a Geographic Information System, enabling the user to do a higher, faster level of analysis than ever before.
The function of the spatial information is key; reference vs. research. We are kidding ourselves if we think 8 1/2" x 11" color maps will make all of our users happy. Let's not fool ourselves into believing that PCGlobe or AutoRoute do anything more than can be done at a mediocre map collection with student staffing. On the other hand they do serve a purpose, especially in a network; the numbe r of mileage questions we have had to answer from campus secretaries has dropped as they have learned how to let AutoRoute do the work for them. We have had ArcView running 1990 population and housing census data for Connecticut by county tract and county block group for almost a year, and maybe 15 maps have been printed... and that is in the Library's general reference area. On the other hand, it is becoming more common to upload tract and block group and block polygons to researchers around the country with specific data variables. These days are becoming remarkable; there are more visits to MAGIC than to the map library. Of course MAGIC is open 24 hours a day, while the map library is open for only eight hours a day.
As librarians we should recognize that we are the interface to spatial information. Every day it seems another site appears on the World Wide Web, another FTP server, another Gopher server and on and on. These sites are usually discovered by users in focused areas, who in turn pass the location along to me. The general user does not often find these sites. Once a week I work at the general re ference desk and try and help unfocused users navigate the Web. It is chaotic, unstable, impermanent and difficult. It is all the things we work to solve in information retrieval in a library. Surfing the Net is an art, not a science. As we begin to populate the Net with our collections, we should remember that we are information scientists with libraries and not collections, that we take a s ystematic approach to collection development, description, access and storage. As the sheer amount of information on the Net explodes, we are the ones who will be expected to pick up the pieces.
The power of multi-use, multi-access, multi-place is amazing; it has the ability to put spatial data resources on the user's workstation, as well as in the library. The paper media has some obvious strengths: it is cheap, permanent and stable. Its drawbacks are also obvious: it can only be used by one person at one place at one time, it is fairly immutable and updating the information is labor a nd time intensive. Digital media also has some obvious strengths and weaknesses: it is very unstable and impermanent and, when you consider the cost of hardware, software, training and networking, it is very expensive; on the other hand it can be used by several people in several places at one time, the cost of absolutely current information is relatively inexpensive, and the information can be easily copied and transmuted to a variety of forms. In as much as the desktop publishing software has made every computer a print shop, the ability to copy vast quantities of data has made every computer a library, or at least a collection. The sophisticated user is learning to leave the vast amounts of data in the virtual map library until they need it, but, they use my library as their own vi rtual harddrives, visiting the library for other, more arcane reasons like asking the help of the librarian to find a particularly difficult piece of information or programming.
Where and what is the data? Spatial data is any geo-referenced data. It can be, of course, a bitmapped image like the scanned historical maps at the University of Georgia's Hargrett Library (http://scarlett.libs.uga.edu) or the CIA map collection at the Casteñada Library (http://www.lib.utexas.edu) or the computer created maps at the University of Minnesota's Bessie Project (http://whiplash.micr o.umn.edu). And, it is TIGER data in ASCII format on CD-ROM or TIGER data coverages in MapInfo or ArcInfo formats on MAGIC (http://magic.lib.uconn.edu/). It is also statistical data like U.S. Bureau of the Census STF1A data, demographic population and housing data, (where the coded variable provides the geocode link), or the telephone book (where the area code and first three digits provide the geocode). Years ago, when I was working on PTOLEMY and I was trying to categorize my client group, the local SAS guru told me, "Data is data." He was right. If it can be designed in space, it can be mapped. The data are everywhere. Mostly the data have not been "collected" or "described." There might be access to it, but usually the user has to know someone and show some sort of need-to-know credentials. I use the analogy that it is manuscript, works-in-progress, yet to be published. The problem is, it will always be in progress and the presses have stopped running.
The materials budget for the Center averages around $14,000 per annum. This includes maps, books, atlases, microform, software and other spatial data packages. This year we MapExpert, AutoRoute, USA and Europe and a number of other applications software, all as 10 user network licenses. Everything else is paper. I generally try and keep the costs of micro and digital to about 25% each of the b udget. Last year we spent about 90% of the available budget on paper, taking advantage of the flood of Soviet Bloc mapping being released.
The equipment in the Center is typical of any organization that has been dealing with hardware for close to a decade. A little bit of this, a little bit of that. In 1984 the Map Library acquired an OCLC M300, the first PC in the Homer Babbidge Library. It was replaced two years later by an M300 XT. This XT was used by the LSCA grant and had an EGA graphics card, an internal CD-ROM and a 20 Mb internal Bernoulli. In 1987 the XT was upgraded to a Dell 386 and all of the internals were transferred to it. That machine is still a key public machine in the Center. It has a math coprocessor, 16 Mb of RAM, a 300 Mb harddrive, and a 14" SVGA monitor. It serves the peripheral 36" x 48" digitizing table. We now use Idrisi and MapInfo as a digitizing programs. The digitizing table gets infre quent, but very intensive use. The other public machine in the Center's Reading Room is a 486DX with 16 Mb of RAM and a 300 Mb harddrive and 14" SVGA monitor. Both of these machines have 4bit TokenRing cards installed and are on the campus backbone.
The MAGIC Fileserver was purchased as a stand alone machine, with the idea that we might be able to find the money to purchase the Novell software. Unfortunately, the Library has had a hard time applying the same level of planning to these sorts of activities as it does to Library System development. We have had to put MAGIC together piecemeal. I first purchased a Tangent 486DX EISA processor with 16 Mb of RAM and a RAID (Redundant Array of Inexpensive Drives) SCSI device. It was 33 Mhtz machine. With it I also bought two 676 Mb harddrives, a 500 Mb tape backup and a 16 Mbit TokenRing Card with expansion to seven drives. The cost was around $8,000. In January, 1995 the motherboard was replaced to boost the CPU to a 90 MHz Pentium and 32 Mb RAM for $2,500. Three 1.2 Gb harddrives were added for $2,600. The parts of the old server were rebuilt as a working computer for $1,500, less one of the 676 Mb drives which was reinstalled in the MAGIC Server bringing it up to a total of 3.736 Gb. The ten user Novell site license was $1,500. We filled the SCSI array by adding a 7 drive CD-ROM mini-tower. The balance of equipment in the Center is for staff use. The librarian's mach ine is a Gateway2000P5-90, the programmer’s is a Gateway2000 P5-120 and the cataloging machine is the Olde Magick, a Tangent 33Mhz 486. All machines are networked. We have a HP 560 Color Inkjet printer and a HP Draftmaster Size E Plotter and three HP 7472 Size A plotters. I think map librarians should make a strong commitment to make maps on map-sized paper. My sense is that the printing of ma ps by federal, state and local government agencies will dry up in five years or so. An irony is that with so much spatial information, hardcopy is often difficult if not impossible. Large format plotters will be necessary in order to supply our users with current mapping. Currently the electrostatic color plotter is the sort of plotter we need.
The Library has purchased a Sun Ultra 1, a high-end workstation. MAGIC has access to it and, with a donation of software from ESRI, will be developing our library of digital geo-spatial data into a digital geo-spatial library. The programmer’s and librarian’s computers have access to the Ultra1 through eXceed, X windows terminal emulation.
Equipment is a tough hurdle. Once you've got it, you've got to maintain it. What you buy is almost immediately out of date. The previously mentioned philosophical underpinnings have guided decisions on equipment purchase. Most of what MAGIC does is store, just like any library. Most users will be able to justify keeping their individual machines upgraded better than the library can justify up grading a collection of computers, printers, digitizers and plotters. It is conceivable that there will always be only two public computers housed in the map library. Collection Development:
The collection development of MAGIC primarily supports the research and teaching needs of the University of Connecticut. As the map library working with the Connecticut State Library, it also considers the citizens of the state as a vital user community, especially of the digital data. With digital data, as with analog data, we can determine our collection development policy by area, scale, "la nguage" and theme. We have limited our data collection available through the Internet to that which is in the public domain. Years ago we purchased street data for Connecticut from MapInfo and realized, belatedly, the limitations of the proprietary one-copy-one-machine model. The prime collection interest level of MAGIC is Connecticut. The secondary interest level is New England, especially th ose features which directly effect Connecticut such as Long Island Sound, the Connecticut River and the transportation corridor between New York and Boston. The third interest level is the United States.
MAGIC is collecting prime interest areas at a scale of 1:100,000 or greater which means TIGER, 1:100,000 DLGs, and 1:24,000 data data of select areas.
TIGER, of course, is distributed through the federal depository program, as are the 1:100,000 DLGs. These data either have been, or will be extracted from the CD-ROMs and converted to supported proprietary formats or the "languages" described below.
1:24,000 data is acquired from the state's Department of Environmental Protection (DEP). This data is generally available as either town coverages or quadrangle coverages. Towns are the primary adminstrative unit in the State of Connecticut. The DEP has put a large amount of data on MAGIC. It had become clear to the Department that MAGIC serves an important economic function; to distribute in formation. The primary users of DEP geo-spatial data is the research community in universities in the State and the engineering and consulting communities. These users have been particularly supportive of the making this data available on the World Wide Web using Web browsers such as Netscape.
MAGIC is collecting its secondary interest area at a scale of 1:100,000 to 1:1,000,000. These data have be taken from the 1:100,000, 1:250,000 Land Use/Land Cover, 30 Second Arc and the Digital Chart of the World. Converting data becomes part of the collection building process for MAGIC. The main problem has been what formats to support. Currently we have been using PC ArcInfo and MapInfo’s ArcLink. These two programs have enabled us to build coverages from TIGER and to transform the DEP’s data to MapInfo MIF format.
Thematic data is going to take map libraries to places we never considered, and they are going to push the limits of our ability to manage internal communication and cooperation. Thematic data is data which can be geo-referenced. Census data, instances of Lyme disease, soil types, pottery shard attributes, automobile accidents... all this and more, as long as it is tied to the Earth's surface.. . but not as maps. This attribute data can be mapped. Do we collect it? Do we, as map librarians, have a responsibility to?
The MARC record is how we have handled bibliographic control in the past. It is not necessarily the best way to retrieve spatial or cartographic information, simply the most expediant in the library environment. The Spatial MetaData Standards developed by the Standards Working Group of the Federal Geographic Data Committee is a parallel record which is being designed and implemented by the dat a community. SMD will provide a standard description of non-textual electronic data.. A crosswalk to allow the librarian to crosswalk the SMD record into MARC, or develop a whole new search strategy is in development. I, for one, am as interested in SMD to MARC as I am MARC to SMD. I have a suspicion that the graphic interfaces to spatial data that will be developed by the GIS community will have a pay-off for our paper map products too. After all, data is data and metadata is metadata.
Cataloging, or describing, spatial data in MAGIC is a top priority which will continue. Collecting without cataloging is building a collection, not the sort of value added resource that users have come to expect from a library.
Because of the multiple dimensions of the data, access to digital spatial information is a complex endeavor. On a paper map, what you see is what you get. Digital data, especially spatial data can be portrayed in a number of formats; as a map, a database, a report, and a spreadsheet. The map can be on a screen, in a file, as an image, on paper... you get the picture. A library needs to set th e limits of what access can be supported. The TIGER discs in a shoebox, or the extracted TIGER data available via the Internet (see the University of Virginia's World Wide Web offering at http://www.lib.virginia.edu/socsci/) As mentioned above, MAGIC extracts and stores all material for the state of Connecticut on its server. This includes TIGER, DLG, the State DEP and so on. The data can be i n three propietary exchange formats: MapInfo MIF, ArcInfo E00 and AutoCAD DXF formats. These are the formats most frequently used by the extended Connecticut GIS community. In addition to the impediment of data conversion, there is the need for software. For the librarian the goal is to get the user to the information as efficiently as possible.
A look at the use statistics of MAGIC over two years illustrates that though use by the education community (.edu) generally exceeds use by the commercial community (.com, .net, and .org), the business use of MAGIC parallels and at times exceeds the research use. Anecdotal evidence supports this. Users often call or e-mail the librarian asking for support; either clarification or further guidance. The business community, at this point in time falls into three categories:
Each of these users are becoming confident in MAGIC’s ability to supply them with the sort of high quality, inexpensive data they need in order to perform their jobs. Each of these communities have approached the library about providing some form of support.