Skip
repetitive navigational links
L-Soft  -  Home of  the  LISTSERV  mailing list  manager LISTSERV(R) 14.5
Skip repetitive navigational links
Previous (more recent) messageNext (less recent) messagePrevious (more recent) in topicNext (less recent) in topicPrevious (more recent) by same authorNext (less recent) by same authorPrevious page (September 2005)Back to main SUBCOOR pageJoin or leave SUBCOORReplyPost a new messageSearchProportional fontNon-proportional fontLog in
Date:         Wed, 28 Sep 2005 11:01:49 -0400
Reply-To:     Subject Coordinates Discussion List <[log in to unmask]>
Sender:       Subject Coordinates Discussion List <[log in to unmask]>
From:         Seanna S W Tsung <[log in to unmask]>
Subject:      Re: Establishment of geographic authority headings at LC
Comments: To: [log in to unmask], [log in to unmask], [log in to unmask]
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline

I don't know if this is a point of great concern in this discussion, but, although we certainly prefer to have BGN authority for any placename we establish, we establish a great many name authorities that are not authorized by BGN. We only establish headings for pieces we have in hand, so much of what appears in GNIS and GeoNet does not have an LC authority record. Conversely, especially for foreign names, we may receive maps or other publications that depict or describe places not in the gazeteers, online or printed. A couple of examples I have handled come to mind. We received extensive large scale mapping of the Central African Republic. Virtually none of these names appeared anywhere, so I established them from the items in hand. Recently, one of our book catalogers consulted with me about a group of several hundred Italian entities called communita montana. These are now administrative, but do not appear in GNIS. I consulted with the BGN specialist, and he confirmed that there were administrative entities, should be done as geographics, and advised me on the desired form. I also consulted with our CPSO geographic expert regarding the form of the headings, which we are now working to correct and update. This is just a long winded way of saying that our geographic authorities and BGNs intersect, but there are also many areas of difference. >>> [log in to unmask] 09/22/05 7:23 PM >>> Joe, I realize I'm disgracefully late in commenting/responding on your very valuable and helpful email. a. authority records: I apologize again!! if someone's already answered this. the relatively short answer is that the library wolrd depends upond the Library f conggress's authoritie records: authorities.loc.gov now, here's the catch. Since LC is real intelligent, they have not tried to make an authority recod for every place name in the world. instead, what lc has done is to accept that any place name the US Board of Geographic Names establishes is absolultely okey-dokey with lc. and - this is much more informal - any place name established by USGS in its GNIS databse is accepted by lc. Lc does establish regional names that bgn doesn't touch. b. 034 field: i may well not be understanding your query. what happened here is that Betsy Mangan and i were looking to change this field so that it did a couple of things: - instead of just bounding boxes, can do non-rectangle pentagons - instead of just degrees minutes seconds, could take any expression of coordinates, including decimal degrees, decimal minutes, decimal secoands, and including coordinates expressed not just with w,e, n, s but with + and - signs. i did specifically check with a programmer here, Catherine Masi, who had worked with literally 2 million metadata records with coordinates in you-name-it, and i askef her what must be specified in the field so a programmer can grab the records and go. this is a couple of years ago and my memory could be failing me - but what i remember is yes, floating point is ok and more than that is essential. am sure i am missign something obvous here. mary Quoting Joe Aufmuth <[log in to unmask]>: > 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 > [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. > > > > > > Mary Lynette Larsgaard Assistant Head, Map and Imagery Laboratory Fund Manager: Geography; Military Science Co-Manager for Map and Imagery Laboratory Fund Davidson Library University of California Santa Barbara CA 93106 805/893-4049 fax 805/893-8799 [log in to unmask] Seanna Tsung Senior cataloging specialist Cataloging Team Geography & Map Division Library of Congress (202) 707-5631 [log in to unmask]


Back to: Top of message | Previous page | Main SUBCOOR page

LISTSERV.LOC.GOV CataList email list search Powered by LISTSERV email list manager