It's in some masochistic way heartening that
many of us are experiencing the same problems:-)
a. MBR for such as areas as 50 states of US:
What one would like to do is have 3 MBR,
one for conterm, one for AK, one of Haw,
and have computer software know that
all 3 apply.
(You're laughing, aren't you? :-) )
What I've been using for MBR is
a bounding box that includes all 50 states
(and therefore also Canada, lots of the Pacific Ocean,
and parts of Mexico ...), but I find
it to be silly. The only reason I'm
doing is is that sometime in the future,
I'd like to replace the MBR with
something that's actually accurate.
b. ap coordinates:
What we're doing is using ArcInfo software
and the graphic index (preferably a photomosaic
but some of indexes are Made By Loving Hands
At Home as spot indexes).
We put the graphic index on a digitizing
table and then tie it to Earth's surface
with at least 3 lat/long spots on it and
then find all 4 corners of each frame.
Yes, it's time-consuming; yes, it's not perfect.
If you'd like to have a copy of the procedure,
I can send it to you as an MSWord document.
We did look into finding center points for
1st and last frames in a flight line and then
finding center points for each frame inbetween
1st and last, but that just doesn't work well
because of pitch/roll/yaw of even the best-flown
air plane.
Mary
Barry, John W. [C] wrote:
>At NGA, we are attempting to georeference appropriate pieces of our
>collections (maps, charts, photos, and docs) that currently are lacking
>coordinates. Some items are obviously more amenable to georeferencing than
>others, and even those that are sometimes require us to use rather labor
>intensive measures to ensure we get an accurate minimum-bounding rectangle
>(MBR). For other non-map items, such as photos, we are attempting to use
>center-point coordinates derived from a combination of the USGS and Geonames
>databases, matching on unique feature name and country. This is a
>hit-or-miss proposition, but it looks to be promising. As for matching item
>dates to specific point sets for administrative areas that may have changed
>boundaries over time, we haven't gotten that far yet. We have yet to find
>ready data sources, so we are in the process of building them ourselves.
>
>An interesting question arises on how you group multi-part countries into
>one MBR, especially when trying to apply coordinates to textual items
>(travel guides, reports, dictionaries, etc...): Would the MBR for the
>United States for instance include Hawaii? Should there be MBR's for CONUS,
>CONUS + Alaska, CONUS + Alaska + Hawaii? This issue arises with many
>countries with detached areas considered at the highest level to be part of
>the country, such as Spain/Balearic Islands and United Kingdom/Northern
>Ireland/Shetlands/etc...
>
>Automated insertion however is still in our future for those limited numbers
>of items that match stringent criteria for each item type and have an
>accurate comprehensive data source for coordinates. We are still in the
>process of building those data sources. We have some online resources we
>have built for Country MBR's, but we have yet to go further down into the
>smaller admin zones (states, provinces, prefectures, counties, etc...). A
>place we are looking to is the ESRI MapInfo data files, which contain
>polygon sets for all these things, from which we could derive the 4 point
>MBR's and 24 point polygon sets (to conform to our Voyager ILS).
>
>I am interested to see where this conversation goes.
>
>v/r,
>John W Barry [C]
>NGA
>Senior Software Engineer
>EDC / e-Library Team
>Bethesda, MD
>(T) 301-227-2103 (F) 301-227-5059
>
>"To understand your enemy, you must walk a mile
>in his shoes. Then, if he is still your enemy,
>you are a mile away and he has no shoes."
>
>
>
>-----Original Message-----
>From: Subject Coordinates Discussion List [mailto:[log in to unmask]] On Behalf
>Of Mary Larsgaard
>Sent: Wednesday, September 07, 2005 1:20 PM
>To: [log in to unmask]
>Subject: Re: [SUBCOOR] batch insertion of coordinates into catalog records
>
>My very limited information on this point is that it's the batch lookup and
>insertion that's difficult, although there are certainly other challenges.
>For example, we have a couple
>of text files that have a geographic area and then the bounding-box
>coordinates:
>- states of U.S.
>- counties of U.S.
>- nations of the world
>
>One would have to make sure date of
>data in the cartographic item matched the date of coordinates in the lists
>(basically 1980s or thereabouts).
>And you'd have to find a way to kick
>out, say, cartographic items with pre-1900 data (ok when that's the date of
>publication; more difficult by a good bit when there's an, e.g., 20th-cent
>date of pub but a pre-1900 date of data. If cataloger didn't use the MARC21
>date-of-data field, 045, time period of content, then it's real difficult),
>to match correct bounding boxes with political area at a given date.
>
>So in theory, one could group one's
>catalog records by the geographic
>areas in the subject headings (but you'd have to figure out a way where a
>record with multiple geographic-area subject headings could have copies in
>each group), and then match against these text files, and then move the
>bounding box coordinates appropriate to the record into MARC21 |d,e,f and g.
>
>You'd also have to have a way to separate out those geog-area subject
>headings that weren't states, counties, natons - which would probably leave:
>- cities; could match those against world gazetteer's cities entries; we'd
>probably use the Alexandria Digital Library's Gazetteer
>http://middleware.alexandria.ucsb.edu/client/gaz/adl/index.jsp
>
>- other political areas (e.g., provinces of Canada; states of Australia):
>I've got a list of coords for Canadian provinces and there are probably
>lists out there for other political areas of nation's countries
>
>- non-polit areas, e.g., "Denver-Julesburg Basin"; these would be the most
>difficult since there aren't any firm boundaries as there are for political
>areas.
>
>Am sure I'm forgetting some of the other "challenges"...
>Mary
>
>
>Archie Warnock wrote:
>
>
>
>>Mary Larsgaard wrote:
>>
>>
>>
>>
>>>**yes indeedy. I remember a couple years back, a friend of mine who
>>>was cataloging photographs of portions of a city was going to enter
>>>coordinates into each record, unwisely mentioned that to someone at
>>>one of the utilities, who told her no-no, can't enter coordinates for
>>>non-cart.mtls. one experiment we'd like to do here at UCSB is download
>>>all of the non-cartmtl records in the library's online catalog, pull
>>>out all the ones that have geographic-area subject headings (which
>>>MARC21 makes very do-able), and then add coordinates to each record
>>>(that's the tricky part), and load records into Alexandria Digital
>>>Library catalog.
>>>
>>>
>>>
>>>
>>Somewhere around here I had some code that I'd glommed to compute the
>>minimum bounding rectangle (MBR) from a polygonal footprint. That
>>simplifies the job to the point where it's relatively easy to do
>>spatial searching.
>>
>>For some time, I've maintained the search engine (Isearch) used on FGDC
>>metadata records and it does spatial searches (overlaps only, but
>>relevance ranked) on bounding rectangles, although it doesn't currently
>>compute the MBR from more complex polygons. It's not real MARC-aware
>>either, but that could be fixed.
>>
>>I'm curious where the coordinates might come from because obviously
>>this is a job that ought to be automated. Are there any
>>easily-available online gazetteers that will provide coordinates from
>>place names which would allow batch-insertion of geographic coordinates?
>>
>>
>>
>>
>>
