Hello Bill et al

Thanks for looking at this Bill. I thought that my earlier post on this
query described a fairly simple process. The following description
seems somewhat complex, though I have never used 'use object list' so
far.

Could I point out that for best results, the preference is to take a
number of images at each location in a mosaic? This means that there
has to be a wait at each point in the mosaic before we say 'go to next
spot'.

Thanks for looking at it. The simplest solution would surely be a hot
key that is programmable to say 'move N by x minutes'. Etc.

Lawrence Harris

>Message: 2
> Date: Thu, 17 Jul 2003 20:53:51 -0500
> From: Bill J Gray <pluto@...>
>Subject: Mosaicking, and more generally...
>
>Hi folks,
>
> A late reply about mosaicking: I've been pondering this idea,
>and may want to generalize it as follows. Please realize that
>this is in the nature of brainstorming; I'm coming up with an
>ideal solution, one that will doubtless require some pruning!
>
> With a mosaic, the scope is pointed at successive fields to
>build up the mosaic. More generally, people just want to go
>to a series of points. Those points may form a grid, or they
>may be a series of target objects: asteroids, variable stars,
>galaxies, etc. So what we may really want is a bit of an
>expansion of Guide's "user object list" capability, to become
>useful as a "points to aim the scope at" capability. This
>dialog is tucked into the Overlays menu, and hasn't gotten
>much use or improvement in a very long time. But it has the
>advantage that much of the necessary code is already in place;
>I don't have to start from scratch.
>
> The improvements I'd envision are as follows:
>
> Within the user object list, one could tell Guide to add an N
>by M grid of objects, at spacing specified through the CCD Frame
>dialog, with a specified amount of overlap (given in arcminutes,
>say), centered on the current screen center. M * N user objects
>would then be added to the list.
>
> It might be possible to specify a "spiral search" order (start
>in the middle and work your way out) versus "start at the upper
>left, scan right, drop one row, scan left, drop one row,
>scan right..." versus "start at upper left, scan down, move
>over to the right one frame, scan up..." Dunno how important
>that is to anyone, though. (Still more specialized would be
>scanning along a line, useful in recovering an asteroid or comet.)
>
> The user-added object dialog already provides the ability to
>delete objects, so if you want the M * N grid minus a couple of
>fields near the corners, you can delete those.
>
> You can already have Guide show user objects on-screen, as a
>user-added dataset. It wouldn't be too tough to have them shown
>as CCD frame rectangles. (Or, for visual observers, as circles
>showing the actual field of view.)
>
> You may instead zip around the sky and add "objects" at the
>places you want to image.
>
> Once you've got your list, you could tell Guide to sort it to
>minimize total slewing distance. This is the "travelling salesman
>problem", usually expressed as: a salesman has to visit a series
>of cities, passing through each only once, and you want to find
>the minimum travel distance. Getting a perfect solution for more
>than about twenty points is usually next to impossible, but I've
>code that can usually get within a few percent of a perfect solution
>without much trouble.
>
> Visual observers of both "goto" and "non-goto" persuasion might
>like this whole system. Even if you're using a Dob, this would
>let you select the objects you want to view, see circles for each
>on-screen, then go out and view them, one after the other, in
>an optimized order. Having the slews automatically done would
>be optional.
>
> People have occasionally asked for multiple user object lists.
>That would become much more important with these proposed changes.
>
> Okay, I've blathered on enough. Any comments?
>
>-- Bill