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.