THE IDEAL SPATIAL-DATA METADATA CREATION WORKSTATION

by

Mary Lynette Larsgaard

Map and Imagery Laboratory, Davidson Library

University of California

Santa Barbara CA 93106

mary@sdc.ucsb.edu

1996

Required:

All that currently is available to catalogers in libraries now - access to

substantial numbers of records online (through 0CLC) - Library of Congress Name

Authority and Subject Authority Files, Catalogers Desktop, Library of Congress

Classification Schedules (to be out sometime this year), fields in order that

makes cataloging easy, rather than in order that database structure permits; and

so forth; plus the following:

a. live background map, at scales appropriate to the item being cataloged,

within

software such that corner points of the item may be "clicked" on, and the

coordinates derived and deposited in the appropriate field. This may tie in

with the development of the Alexandria Atlas. Coordinates should also be

obtainable, in a cut-and-paste/click-on way, from the Gazetteer.

Rationale: The single most important, most time-consuming, and most error-prone

part of cataloging spatial data is getting the coordinates. What is needed is a

"live map" which would have a rheostat-like (sliding) scale, so that the scale

of the map displayed on the cataloger's workstation monitor would be appropriate

to the item being cataloged. For example, for air photos at 1:6,000, the

background map should be about 1:20,000. Part of the research here would be to

figure out what the optimum background-map-scale to scale of item being cataloged

ratio is.

Would it be possible to get corner points from the photomosaics, using

center-point information? Perhaps by getting coordinates for first and last

frames in a flightline, and then deriving from that the coordinates for each

frames in between those two.

It is also very important to move from bounding-rectangle coordinates to g-ring

polygons. For example, the bounding rectangle for California takes in Nevada

and parts of the south Pacific 0cean; California is in actuality an irregular

polygon, which the g-ring polygon capabilities of USMARC can handle.

b. ability to locate north arrow on the item

c. ability to locate on the item a bar scale, N0T in representative fraction,

but in e.g. feet, miles, meters, etc.

Example: 0 1 2

l_____l______l

Miles

Users of spatial data need to have orientation and some idea of distances

represented on the item; time of cataloging seems to be a good time to get this

work done.

d. the ADL Gazetteer for checking place names, getting correct forms, and

obtaining coordinates

e. ability quickly and easily to convert the coordinates given on maps (which

are always in degrees/minutes/seconds) to the decimal degrees required by

Alexandria

f. spell-checking

g. online digital data: use PURL (Persistent URL software) for the location of

items available over the Web.

h. training for spatial-data catalogers in image processing and geographic

information systems software, aimed toward the particular uses catalogers need.

i. multilevel description

Sheet-level/frame-level access is essential, since users request items at that

level, rather than needing to see every sheet in a series.

For sheets in any given series, or for frames in any given flight, the following

is needed:

i. ability to scan in item: maps can easily be up to 4 feet by 5 feet,

and be very detailed, all of which makes considerable demands on a scanning.

Ideally, one would want to be able to put in digital form each of the separates

that were used for printing the map, or be able to separate out the various

layers of information after scanning, in order that users would be able to

manipulate the information in each layer.

ii. ability to link record to other records - parent to child, host to

part, one edition to other editions, one physical format to another physical

format.

j. indexes for air-photo flights and map series: These indexes are extremely

important items; they need to be put in digital form, and if possible used both

for a user to request a given frame/sheet, and for the library to check in the

frames/sheets it has.

k. retrospective cataloging of large map and air-photo collections: Ways to do

this expeditiously would be warmly welcomed by map libraries. For example, with

map collections, one hauls the maps to the computer terminal. Given the

relative weights of the materials involved, it would seem more sensible to haul

the terminal to the maps.

l. legend as part of metadata

m. header as part of metadata

n. being able to generate subject headings from coordinates, and coordinates

from subject headings

o. automatic extraction of metadata

-extraction of metadata from digital files

-machine entry of as many fields as possible in child-level records for map

series and remote-sensing images

p. idea of concatenated fields in USMARC

q. cataloging for the non-cataloger

r. cataloging workforms should have natural-language pulldowns for coded fields,

so catalogers don't have to memorize all those irritatingly non-mnemonic codes (or

indeed any at all), and also pulldowns for all fields with (relatively) limited

number of values.

HTML 3.2 Checked!