Msg: 7038 *Conference*

03-31-97 19:05:39

From: RON WIESEN

To : TOM UPTON

Subj: REPLY TO MSG #7032 (SOL CENTRIC VIEW)

Here's some considerations and recommendations for imaging the local 
neighborhood with the M100.
 
Image by pixel.  The 240 by 64 pixel array of the LCD is more appropriate to
star imaging than the 40 by 8 character array which it forms.
 
Use a horiz/vert aspect ratio that is integral.  The 40 by 8 character array is
integral at 5:1 but character imaging is not recommended.  The entire pixel
array is not integral (3.75:1) so some part of the LCD must not be used for
star imaging.  The choices of integral aspects for the pixel array are: 1:1
(square) simulates human sight but leaves much unused screen area 2:1 3:1
(recommended) leaves a bit of unused screen area 4:1  no unused screen area
 
Use a base 60 scaler.  This allows scaler division by up to ten integrals: 2,
3, 4, 5, 6, 10, 12, 15, and 30.  It also has an integral relation to most of
the angular arc units in common use for astronomic coordinates: degree (360),
minute (60), and second (60) hour, minute (60), and second (60)
 
Don't use spatial data (perhaps what you mean by snapshots) where both empty
space and stars are specified.  Much data would specify empty space.  Instead,
use only data to specify the stars.  This way, data capacity constraints limit
only the amount of stars and the precision of their specification.
 
Some coordinate reference system must be used - the simple ones are 2-axis.
Use an existing one that is common to astronomy, such as: Right
Ascension/Declination - most common Azimuth/Altitude - requires a reference
Earth position and date/time
 
I don't know your ultimate purpose in imaging the local neighborhood -
maybe your doing it just for "grins" or maybe you have some very specific
reason.  What follows covers a lot of ground - some may not be relevent to your
purpose.
 
The most simple image, probably not what you have in mind, does provide clues
to more complex imaging.  This is a no frills whole-sky panaramic view.  The
LCD represents an unrolled cyclinder where top & bottom LCD edges are +90 & -90
degree up/down limits, and the left/right view is 360 degree panaramic
cyclinder surface which is "cut vertically" and unrolled so that the left &
right LCD edges represent "the cut".  No navigation (view scrolling) is needed
- the whole sky is seen.  Of course Mercater distortion is infinite at the top
& bottom limits - a star at either limit can not be a "point" but must be a
horizontal line going all the way across between left & right limits of view.
Its one big advantage is that spatial data (empty space and stars) is practical
because only one view exists (that's why no navigation is needed).
 
A wee bit more complex is to allow view navigation of the whole-sky panarama.
Navigating among just 4 views immediately shows the disasvantage of spatial
data: either 4 "snapshots" are needed, or a master "snapshot" must undergo
"mathematic rotation/inversion" before it can be presented as one of the views.
Of course the master can be made to serve directly as one of the four views but
the other three views need "math".  Views are: master, master with inversion of
up/down and of left/right - (bend over 180 degrees and look between your 
knees), master with 180 degree horiz rotation (turn around), and master with a
90 degree down rotation (look at your feet - what was "down" has become
"forward").  This fourth view inverses the Mercater distortion: an "overhead"
star that looked like a horizontal line now looks like a point while a star
that was a point "stright ahead" now expands and becomes a line.
 
Where a view along an axis is confined to less than 180 degrees, infinite
Mercater distortion is avoided.  Where the sphere of space is divided into a
set of "maps" for viewing, navigation is a must.  View presentation can get
complex.  Consider a set of maps where each provides a view that is 90 degrees
left/right by 30 degrees up/down (a 3:1 aspect ratio as recommended).
Navigation left/right "aims" you in four directions.  Navigation up/down
"tilts" you in twelve ways.  There are 48 rectangular view maps as shown below.
Note map [Z] which is centered at 000degHoriz, 000degVert on some coordinate
reference.  Now consider map [Z'] which is centered at 180degHoriz, 180degVert.
Everything seen in map [Z] appears also in map [Z'] except with inversion of
up/down and of left/right.
 
         | 135to225 | 225to315 | 315to045 | 045to135 |
165to195 |  map Z'  |          |          |          |
135to165 |          |          |          |          |
105to135 |          |          |          |          |
075to105 |          |          |          |          |
045to075 |          |          |          |          |
015to045 |          |          |          |          |
345to015 |          |          |  map Z   |          |
315to345 |          |          |          |          |
285to315 |          |          |          |          |
255to285 |          |          |          |          |
225to255 |          |          |          |          |
195to225 |          |          |          |          |
 
A useful adjunct to the previous example of "mapped space" is to provide
navigation by an integral fraction of the map dimensions.  Navigation by a 1/3
step in each axis is good - one step on an axis alters only 1/3 of the view, so
what's "new" is seen in context to the "center" and "one side" of the prior
view.  This also solves the "problem" of star positions at exact map
boundaries.  In the example, navigation left/right is by 30 degrees and up/down
is by 10 degrees.
 
Assuming data specifies 2-axis star positions and integral fraction nvigation
steps, then I recommend split-datum structure with one axis as the key - the
key axis is whichever one you expect to get the most "navigation" by the
operator.  With vertical navigation steps being less than horizontal, vertical
navigation will prevail.  Considered as lists, the key list has "vertical"
ordinates, arranged in ascending order, for every star in your catalog.  The
other list has the "horizontal" ordinate of the stars and its order mimics the
order of the key list.  The star with the lowest vertical ordinate is "first"
in both lists.  For a particular "view" there is: the lower and upper vertical
ordinate limits, and the lower and upper horizontal ordinate limits.  After
"blanking" (all or part of) the screen to "paint empty space" stars are
"painted" via their coordinates.  One fast search of the key list finds these
"indexes", if any, for stars nearest to and between the limits.  A low and a
high index result - where only one star is within limits, its index is the low
as well as the high.  All stars inclusive of the index limits are "candidates"
for "painting" on the view.  A search of the other list, within the same index
limits, "qualifies" the candidates: where a horizontal ordinate is between the 
lower and upper ordinate limits of view the star is "painted", elsewise it's
skipped.