LPOD May 18, 2008
UNIFIED LUNAR DATA TOOL
image from USGS PIGWAD
Last week I worked on a grant application to NASA to study impacts of possible binary asteroids on the Moon. A good example is the pair Plato K and KA, identified by the septum (ridge) between the adjacent rims. One goal of the proposal would be to compile a catalog of possible binary impacts or doublet craters. How should the task be organized? First a homogenous global image database of high resolution and low to moderate illumination is required. Such a database does not exist for the Moon - the best now is Clementine, which has global high res coverage but latitudinally different Sun angles. Someday we may have more homogeneous datasets from SMART-1, Kaguya, Chang'e, Chandrayaan-1 or Lunar Reconnaissance Orbiter, but the low rate of data release from these orbiters is not encouraging. Sadly the best option today is to use Lunar Orbiter IV images for most of the nearside, with Clementine for the farside. For each doublet found it is necessary to collect various pieces of data: crater diameters, latitude and longitude, azimuthal orientation, nomenclature, US Geological Survey stratigraphic age, and mare surface age where appropriate, How can these diverse pieces of information be efficiently collected? I don't think there is a way. The USGS has three online references that can be used to compile such information for doublets. Map-A-Planet allows coordinates to be rapidly determined, and the Gazetteer of Planetary Nomenclature maps can be consulted to see if either of the doublets has a name. Stratigraphic names have to be read from the 1970s era geologic maps, and for doublets formed on maria the model age of the mare surface can be read from the maps of Hiesinger and colleagues. There is a real need for a unified lunar data tool - a geographic information system that allows all of these, and other datasets to be easily brought together and co-registered. The US Geologic Survey has a tool that does some of this. Planetary Interactive G.I.S.-on-the-Web Analyzable Database or PIGWAG shows multiple data sets, positions and nomenclature, but is slow and awkward to use. The Virtual Moon Atlas also does part of it and is easier and faster to use - but it is not a web application and runs only on PCs. LTVT also does part of this but suffers (in my opinion) from the same handicap as VMA. I hope it will be possible someday for one tool to bring together all major lunar data sets for analysis and exploration - and I think amateurs will be the ones to do it!
Chuck Wood
COMMENTS
To [/LPOD%20Comments post comments] regarding this LPOD, please click here and enter your text in the space below. You will not see the Edit tab unless you register for the wiki. Please do not edit the LPOD itself!
(1) Chuck--As soon as I read your description of binary impacts, I thought of the craters Moretus and Short at the south pole. They appear to have a septum (ridge) between the craters. Do they fit the category?
--Bill
(2) Chuck: Good luck with your proposal!
I certainly agree that the [/USGS USGS] should be applauded and encouraged in their current efforts to make more easily accessible the lunar data under their purview. I have to wonder, however, if they should not be encouraged to invest their effort in doing a few things well instead of many things not so well. There are already (without any explanation that I know of) two alternative [/Map-a-Planet Map-a-Planets] (neither of which seems to work quite perfectly, and neither of which provides the projection options needed to properly display high latitude regions) and now PIGWAD appears to offer seven additional interfaces to sometimes the same, sometimes different data. From the on-screen example you show, this particular interface seems to offer a mix of datasets adjusted to the latest USGS control network (the construction of which is itself poorly documented), and others that are not -- so finding consistent coordinates and knowing what system they are expressed in may not be as simple as you imply.
Something else that bothers me is whether any of these interfaces provide a simple way to go back to the source of the images/data that are being displayed. Does PIGWAD tell you that the upper part of this screen has been drawn with Lunar Orbiter IV-084H (taken May 16, 1967 UT at 17:08:57 UT from a known location at a known distance above the Moon)? or that the lower part was drawn with Lunar Orbiter IV-083H (taken at 16:36:52 UT from a different, but equally well-known location)? or that blemishes below and between Lindenau E (the small crater torn by the clumsy seam) and [/Rothmann Rothmann] that appear in the original of this frame may have been artificially removed making the fidelity of the display suspect? Also, because of the bad seam one can make two alternative estimates of the distance from Lindenau to Lindenau E: the distance looks shorter in the upper section than in the lower section, and without being able to access the originals one is going to be at a loss as to whether [/Lindenau Lindenau] has multiple terraces in its northeast wall (this is not a problem in the originals, since when LTVT registers them to the [/ULCN#ULCN_1994 1994 control network] and remaps them to a uniform projection they overlap within a couple of pixels).
But I've been taught not to look a gift horse in the mouth, so I won't continue with such unhelpful comments.
I don't know enough about web programming to know if what you are suggesting is feasible or not. Since the modern lunar (and other planetary) data sets are already immense (and growing every day) it would seem to require the cooperation of the keeper of each set to provide access to its contents in some simple, uniform and efficient way. Then perhaps someone could provide a single interface that would pull up the contributions from these diverse sets pertaining to a particular location on the Moon; but I doubt it would be an amateur who would organize this.
In my own opinion, what is needed more than new interfaces to existing global data sets is access to individual (well-documented) images and data for specific regions. Wouldn't it be nice if you were preparing an LPOD about [/Lindenau Lindenau] you could, at the push of button, see a list of all the images of that region that exist from Lunar Orbiter, Apollo, Clementine, Kaguya, etc. as well as the thousands of uncataloged Earth-based photos wasting away in the archives of Lunar and Planetary Institute, Pic du Midi, Mt. Wilson, etc. and the millions more in amateur collections -- each telling you the exact date, time and location from which it was obtained and providing mouse-click access to the actual image? [/LTVT LTVT] demonstrates that this is entirely feasible, but it would require an immense effort and a great deal of cooperation between a great many interested parties to make such data available in that way.
-- Jim Mosher
(3) Bill -
I don't see the ridge you see, but these two craters aren't doublets because Short is much older than Moretus and doublets are simultaneous impacts. I bet a number of the large craters are (see Hainzel A & C for a possibility) but we haven't recognized them yet.
Jim - I too wonder about the multiplicity of USGS image display systems - I wish there was one that would do everything well! But then somebody like me would probably complain that it doesn't work on a Mac!
Regarding your last paragraph - The Moon Wiki does some of what you describe, but as you know it involves a lot of tedious manual labor - as well as some of your programing for the Lunar Orbiter and maps - to bring the few images together that we do. Your collection of images for LTVT is a start, but very labor intensive. SInce all spacecraft images are owned by governments it will probably take an agency like NASA to work out exchanges of image and other data, and then the USGS to convert it all to one system that amateurs could then use to make more easily available.
Chuck
(4) Chuck--The Photo Gallery file moretus_040807_03h36tu.jpg gave me the impression that there was a septum between Moretus and Short. I didn't know about the age difference between the craters. As you mention, they could not be the product of a binary impact.
I imagine, however, that craters of different ages can be joined by a septum, giving the impression that they are binaries. Is there a category for false binaries?
--Bill
(5) Chuck,
My last paragraph was probably a bit inscrutable. LTVT actually comes with no images. Instead, the user supplies calibration data (and the hard drive location) for those he or she is interested in working with. Each of these pictures has to be manually "registered" by supplying the date, time, observing location, image size and X-Y pixel locations of any two observable features in that image. What LTVT demonstrates is that given a location of interest on the Moon (specified not by name -- as in the-Moon Wiki -- but by selenographic longitude/latitude), a modern computer can use such simple and readily available data to extremely rapidly search through that list, determine if the location of interest falls within the boundaries of a frame, and what the lighting conditions at that point would be (the sun's elevation and azimuth as seen from the point of interest). It can then sort that information and instantly present a clickable list of images ranked by increasing or decreasing sun angle and each guaranteed to show the point of interest. All images of a particular named feature can also be located simply by going to that lat/lon and then searching for images including that point.
The only other thing similar to this that I am aware of is the search function in Arizona State University's Apollo Image Archive, which can only be accessed through a clickable map and uses (I think) the less reliable system of trying to guess whether the point of interest falls on the plate using the archived corner coordinates or "image footprint" (it also does not determine if the point of interest is in sunlight or not). Some of the [/LPI LPI] image searches may also do something vaguely similar, but they seem to tell you mostly if they have an image whose center falls within a lat/lon region you specify (which fails a great deal of the time because an image can easily show a feature without being centered on it). And those LPI searches based on named features -- as handy as they may be -- rely entirely on some image cataloger having listed that feature as appearing on the frame.
What I was trying to say is that something like the extremely robust and reliable LTVT search technology could be extended to much larger image sets if the data set holders and compilers were interested in developing and posting the simple image registration information that is required for something like this to work, and placed the images in locations from which they could be easily retrieved once a picture of interest had been located.
But perhaps the "Imagery" tab in today's screenshot already does this?
-- Jim
