|
||||||||||
|
Navigating through the /images directory in search of a particular image can be very time consuming. Creating thumbnail images that show miniature versions of several images on a single page would make browsing the library much faster. (See Star Trek Composites for an example.) Software exists to help automate creation of the thumbnails, but the software may generate an index page that includes a thumbnail of every single image in a directory. In /images, that one page could be incredibly big.
We could reorganize /images into /images/1994, /images/1995, etc. This could require going through every document on the web site to search for references to images and correct the URL for the image. That may not be worth the effort unless it makes it significantly easier to maintain the data. It might be possible to write a search engine that could do it all in one pass something like this:
make list of all files repeat for each file repeat for all text in the file if textitem = "<img src="/images/asi1994" then textitem = <"img src="/images/1994/asi1994" store textitem in file else if textitem = "<img src="/images/asi1995" then textitem = <"img src="/images/1995/asi1995" store textitem in file else if textitem = "<img src="/images/asi1996" then textitem = <"img src="/images/1996/asi1996" store textitem in file else if textitem = "<img src="/images/asi1997" then textitem = <"img src="/images/1997/asi1997" store textitem in file end if end repeat ! end scanning individual file end repeat ! end allfiles loop
The program would also have to search for variations, such as <img src = "http://www.asi.org/images/...">, references to image URL's in the text without the <img> tag, and whatever else is out there in that mess.
The resulting indexes would still be large, but at least they would be bounded by one year intervals.
We could, instead, rely on creating our own index files which use the thumbnails created by this indexing program. That would provide a lot more flexibility. The index files need not even be in /images; they could be in the web section of /adb/09/, or better yet as an appendix to the Data Book that parallels the index of html documents.
If you look at the space flight imagery library they offer at JSC, you'll see that they have a nice standard layout for their library. Each image has a separate description page, with all the data about that image. We could adapt that format to our purposes, using something like this:
+---------------------------------------------------------------+ | | | +-------------+ imagenum imagedate | | | | Title: imagetitle | | | thumbnail | Source: imagesource | | | | Key words: keywords | | | | ADB refs: adbsectionnumbers | | +-------------+ File Size: _____ KB File Type: [gif] | | Image Size: ____ H x ____ W x ____ Clrs | | | | Description | | | | | | | | | | Comments | | | | | | Copyright Info | | | | | | [ Image Search ] | | ----------------------------------------------------------- | | [ ] [ ] [NavBar] [ ] [ ] | | ----------------------------------------------------------- | +---------------------------------------------------------------+
If we had a set of thumbnails and a clever programmer, we might automatically generate these pages using the information currently available in the /index-199x.html files in /images.
A similar page layout could be used as an image submittal form that somehow links to TeamSite to upload a file to the directory where we store incoming images.
If we do this, we would want to store automatically generated indexing information and the thumbnails in a separate directory, not in /images, to avoid cluttering up /images.
| Previous document | Table of contents for this section | Next document |
Artemis Project | Artemis Society | Artemis Data Book | FAQ | Reference Mission | Catalog |