Date:Wed, 14 Sep 2005 16:45:22 -0400
Reply-To:Subject Coordinates Discussion List <[log in to unmask]>
Sender:Subject Coordinates Discussion List <[log in to unmask]>
From:Joe Aufmuth <[log in to unmask]>
Subject:Re: Question on form of coordinates
Comments:To: Subject Coordinates Discussion List <[log in to unmask]>
Content-Type:text/plain; charset="iso-8859-1"
Just a couple of comments, and remember my perspective is as a GIS Librarian
educated in Geomatics not library science, but I am learning! I am a glad
to see this forum bringing together concerns from a cross section of the
information management/systems/science disciplines. I have been involved
with GIS consulting for the past 15 years, but only with libraries for the
past 5 years. I wish I had been involved with libraries 10 years ago when
spatial meta data standards were being developed and proposals were made for
their MARC implementation. However as a newly appointed ALA MAGERT CUAC
representative I am honored to have this opportunity to represent geospatial
interests and work towards solutions on these issues.
I am obviously playing catch-up. Is there a mechanism for the spatial data
community to provide input to improve the usability of the fields in
Proposal No. 94-17, or has that proverbial ship already sailed? Can we
re-establish a formal channel/working group to address implementation, or is
there an existing group? Perhaps such a representative working group will
be the outcome of this discussion list. It would be great if the authority
records could become the relational database for the bibliographic records
and lead to a GIS interface. Which begs a question about the data formats
for coordinate fields in an authority record. Are they alphanumeric or
floating point?
On authority records for place names: If these have been mentioned in a
previous discussion, please excuse any duplication, but I presume we are all
aware of the Board of Geographic Names (http://geonames.usgs.gov/bgn.html),
the USGS' Geographic Names and Information System
(http://geonames.usgs.gov/redirect.html), and the NGA's GEOnet Names Server
for foreign names (http://gnswww.nga.mil/geonames/GNS/index.jsp). Besides
the current feature names and descriptions which have single Long/Lat
coordinates or bounding boxes, USGS also has a list of historic US feature
names and coordinates. These would be a great starting point. Or have they
already been ingested? One problem we have discussed amongst GIS users in
Florida (but have not gone very far with solving), is how to create an
authority of existing historic local names for the same "official" GNIS
names. As Rebecca points out, we could easily add an alternate name.
Realizing of course that over time we may end up with several aliases as
well as differing coordinates for the same places. A related topic was
brought up at CUAC in May 2005. For historical analysis, there is great
interest in preserving as much historic spatial information as possible. If
we change the authority record coordinates and the date, how will we
preserve historic changes?
On 034, 255 fields: Can the data type for these fields be changed from
alphanumeric to floating point? I am sure that question will get a good
laugh. To work around not being able to use the character based 034 or 255
directly, a colleague and I created a spatially searchable catalog interface
using ArcGIS and the GNIS database for Florida. We created a point feature
class GIS created from the GNIS coordinate file and populated the database
with "hot-linked" purl scripts. A patron could spatially search and then
click on the hotlink to run the script and launch a search of our catalog by
place name. Additional GIS overlays allowed us to enhance searching using
other tabular attributes besides a geographic coordinate reference. This is
a very static approach. A more dynamic approach would be to create a
searchable GIS database from integer MARC coordinate fields. Or, search
the MARC records by a coordinate range and then use the MBR or single
coordinate pairs from MARC to create a map/"area of interest".
Lastly, to address Rebecca's comment:
"A change was made to the format not long ago to make the data variable
length, because it seemed too limiting to use a fixed length number of
characters in a format that was not widely used (the format that Colleen
asked about, e.g. N0421510). So I assume from what you're saying that the
"+" and "-" need to be extracted to use the data? I would say that when the
change was made noone brought up this point-- we just didn't get enough
feedback from experts on geospatial data."
I am not sure when the format length was adjusted, but I am sure that at the
time the change was made I was not in a position in my library career to
provide feedback. I also am not sure how or if feedback was solicited from
the spatial data experts outside the libraries. When the length was
changed, was the data type also changed from alphanumeric to floating point
or integer? As evidenced by the leading "+" and "0" used for longitudinal
coordinates, my guess is that the field is still alphanumeric. As you know,
a leading "+" and "0" are not used with real integer values and a "-" sign
could indicate a valid real integer value. So yes, in order to be able to
search for a integer value based upon a user specified range (MBR) you would
first have to generate a report of MARC's alphanumeric coordinate strings
and then strip out the leading "+" and "0" (or parse out the actual values)
before "dumping" the coordinates into software to do a mathematical search,
or create a GIS database. I suppose you could also write a program to read
the alphanumeric string, strip out the leading "+" and "0" and pass the
string as a floating point variable for comparison against the user's
specified search range. As you also know, the "+" sign is implied with
positive values and the "0" is just a hold-over from the DDD/MM/SS format.
Both are not really needed. Additionally, a decimal degree value allows a
single search statement, where as ddmmss requires additional comparisons of
dd, mm, and ss against the user's specified range. Of course you could also
write a program interface to convert the string ddmmss to integer decimal
degrees and then perform the search.
Hope these comments are of interest and assistance.
Joe
Joe Aufmuth
GIS coordinator
George A. Smathers Libraries
Government Documents
University of Florida
P.O. Box 117001
Gainesville, Florida 32611-7001
352-273-0367
Fax: 352-392-3357
mapper@uflib.ufl.edu <mailto:mapper@uflib.ufl.edu>
[log in to unmask] <mailto:[log in to unmask]>
-----Original Message-----
From: Subject Coordinates Discussion List [mailto:[log in to unmask]]On
Behalf Of Rebecca S. Guenther
Sent: Friday, September 09, 2005 10:30 AM
To: [log in to unmask]
Subject: Re: [SUBCOOR] Question on form of coordinates
I've been following some of the discussion on this list but have been slow
to respond. I'm not sure that I understand all the needs of the geospatial
community, but do have some thoughts on some of the discussion.
Thus far most of this discussion has been about adding coordinates to
bibliographic records to be used for more effective searching of places. I
think it would be more effective to add the coordinates to authority
records instead (or at least as an alternative). The reason is that an
authority record is intended to include metadata about the particular
entity. So for a person, one could expect an authority record to tell you
about that person, like where he/she is employed, when the person was born
and died, alternate names. Likewise for a place that authority record
could give information about where it is located-- it would be appropriate
to include a field to contain coordinates. If over time those coordinates
changed because the jurisdiction it covers has changed they could be
qualified by date. That way there would be one authoritative source to
look for this information. Of course up until now we haven't done that
with geographic headings, but I would favor developing a proposal to add
the information needed. I would also favor adapting one of the existing
fields (034 or 255) rather than defining yet a new field to do what is
needed-- and add them to the authority format.
Of course for this approach to be effective it would require that systems
be able to use it-- a closer interaction between authority and
bibliographic records. And the lack of that is the reason why there is
this desire to add everything to the bibliographic record. But it does
require analyzing where the information rightfully belongs, perhaps in
terms of a entity model like FRBR, where there is a distinction between
entities and where to record such information. Then the goal would be to
get the vendors to implement an effective means of using the data.
I think this list is a good vehicle to discuss some of these issues. It
would be nice if we could present a discussion paper at the Midwinter
MARBI meetings to start getting them out on the table so that any
necessary proposals for changes can be considered maybe at the annual
meeting.
See also below some specific comments on an earlier message.
On Tue, 16 Aug 2005, Joe Aufmuth wrote:
> The Alexandria project is a prime example of an integer field which will
> allow a variable range search. Where as a leading "+" sign and 0 place
> holder in MARC limits the records to character based searches. Therefore
> additional programming would be required for any MARC catalog interface to
> extract the integer values from the character set and then compare them
> against a patron's request. It's not the most efficient method. I
presume
> at the time the change was made to accept some format of decimal degree
> coordinates, a visual spatial catalog search engine was not envisioned.
A change was made to the format not long ago to make the data variable
length, because it seemed too limiting to use a fixed length number of
characters in a format that was not widely used (the format that Colleen
asked about, e.g. N0421510). So I assume from what you're saying that the
"+" and "-" need to be extracted to use the data? I would say that when
the change was made noone brought up this point-- we just didn't get
enough feedback from experts on geospatial data.
> While mapping international dateline spatial data is tricky, treating them
> as a series of points is not a problem. If the bounding box column names
> are well defined only 2 coordinate pairs are needed, I.E. Upper Left X,
> Upper left Y , Lower Right X and Lower Right Y. By definition of a box
any
> system could read the UL and LR coordinates and calculate the remaining 2
> corners. Or, the additional X,Y coordinates for LL and LR columns could
be
> included and calculated by a cataloging macro. If the points are treated
as
> a set of coordinates in a single field additional programming also would
be
> required to extract the integer values from the set.
>
> Has anyone seen the Geographic Code Indexing thread on the Maps-L
listserv.
> Perhaps we can tie in those discussions with ours? I am not a cataloger
and
> have a very basic question: what does the 052 field offer in terms of
format
> (integer vs. character), indexing, searching, and reporting?
>
> And one last larger question. What will come of our discussions? Where
is
> MARC headed in terms of compatibility with FGDC or other spatial metadata
> standards? -- sorry if this is off the thread's topic, but it is another
> major issue facing GIS Librarians and digital spatial data related to MARC
> records. Will additional MARC fields for digital spatial metadata, be
> created? Will existing field formats be changed from character based to
> integer based to enhance searching? What is the long term vision for MARC
> and spatial metadata? My focus is rather biased towards digital spatial
> data indexes and metadata search engines for our patrons.
When the Content Standard for Geospatial Metadata was first approved (I
think it was 1994), a large proposal went to MARBI to add all elements
contained in it so that MARC could carry such data (Proposal No. 94-17). I
recall that someone commented that they never saw MARBI approve so many
fields at once. We have had very little feedback on the use of any of
those changes that were made. Without input from the geospatial community
we can't improve the format for its use. Certainly there is a broad
recognition that geospatial data is important in the present information
environment and we want to accommodate it in MARC as well as possible. So
some focused discussion on specific problems and solutions would be
welcome.
Rebecca
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^ Rebecca S. Guenther ^^
^^ Senior Networking and Standards Specialist ^^
^^ Network Development and MARC Standards Office ^^
^^ 1st and Independence Ave. SE ^^
^^ Library of Congress ^^
^^ Washington, DC 20540-4402 ^^
^^ (202) 707-5092 (voice) (202) 707-0115 (FAX) ^^
^^ [log in to unmask] ^^
^^ ^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Sorry to ramble on
>
> Joe
>
>
> Joe Aufmuth
> GIS coordinator
> George A. Smathers Libraries
> Government Documents
> University of Florida
> P.O. Box 117001
> Gainesville, Florida 32611-7001
> 352-273-0367
> Fax: 352-392-3357
> [log in to unmask] <mailto:[log in to unmask]>
>
>
>
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Subject Coordinates Discussion List [mailto:[log in to unmask]]On
> Behalf Of Rebecca S. Guenther
> Sent: Tuesday, August 16, 2005 10:06 AM
> To: [log in to unmask]
> Subject: Re: [SUBCOOR] Question on form of coordinates
>
>
> For the record, I thought I would mention that a few years ago we made
> some changes to the MARC field that contains the structured form of
> coordinates, field 034 (MARC also has a field for the human readable form,
> field 255). Field 034 has separate data elements (subfields) for
> westernmost, easternmost, northernmost and southernmost coordinates. We
> changed it to allow for variable length values and to use either the form
> Colleen asked about (e.g. N0421510) or decimal degree format (e.g.
> +079.533265, etc.). At the time we made this change, we were told that
> there was not a need to specify the format used, since the format is
> easily recognized by the number of characters and the placement of the
> decimal point.
>
> Rebecca
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ^^ Rebecca S. Guenther ^^
> ^^ Senior Networking and Standards Specialist ^^
> ^^ Network Development and MARC Standards Office ^^
> ^^ 1st and Independence Ave. SE ^^
> ^^ Library of Congress ^^
> ^^ Washington, DC 20540-4402 ^^
> ^^ (202) 707-5092 (voice) (202) 707-0115 (FAX) ^^
> ^^ [log in to unmask] ^^
> ^^ ^^
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> On Mon, 15 Aug 2005, Archie Warnock wrote:
>
> > Colleen R. Cahill wrote:
> > > As a map cataloger, I primarily deal with coordinates in two forms:
> > > human-readable geographic coodinates (i.e. North 42 degrees, 15
minutes,
> > > 10 seconds) and machine-readable decimal degrees (i.e. N0421510). For
> the
> > > proposed subject coodinates, a machine-readable form of coordinates is
> > > needed and so I always think of decimal coordinates. This is form a
> > > standard used much? Are there any other (better or worse) ways used
to
> > > present coordinates?
> >
> > Thanks for getting this started, Colleen.
> >
> > Decimal degress are, I think, to be preferred in almost all cases
> > although there are certainly occasional needs for alternative coordinate
> > reference systems. Decimal degrees are trivial for machines to parse,
> > they sort sensibly and are even relatively easy for humans to read.
> >
> > Metadata standards, eg, the Z39.50 GEO Profile
> > (http://www.blueangeltech.com/standards/GeoProfile/geo22.htm), the FGDC
> > Content Standard for Digital Geospatial Metadata (CSDGM -
> > http://www.fgdc.gov/metadata/csdgm/), various OGC documents
> > (http://portal.opengeospatial.org/files/?artifact_id=1094,
> > https://portal.opengeospatial.org/files/?artifact_id=6716), to the
> > extent that they address spatial coordinates at all, require the use of
> > decimal degrees.
> >
> > A bigger issue with geographic coordinates, it seems to me, is ensuring
> > that the coordinates are treated together, not as individual bounding
> > coordinates. That is, a bounding rectangle needs to be considered as a
> > _set_ of 4 coordinates and handled together, rather than as 4
> > independent points. Otherwise, footprints that cross the International
> > Date Line become much harder to handle.
> >
> > --
> > Archie
> >
> > -- Archie Warnock [log in to unmask]
> > -- A/WWW Enterprises www.awcubed.com
> > -- As a matter of fact, I _do_ speak for my employer.
> >
>
