Index: trunk/Ohana/src/libdvo/doc/dvo-structures.txt
===================================================================
--- trunk/Ohana/src/libdvo/doc/dvo-structures.txt	(revision 11991)
+++ trunk/Ohana/src/libdvo/doc/dvo-structures.txt	(revision 12332)
@@ -1,2 +1,76 @@
+
+2007.02.22
+
+I have several DVO improvements to implement.  I need to plan them a
+bit carefully.  Here are my thoughts on these updates.
+
+- add chip X,Y to measure table
+
+  this is a fairly simple addition.  In addstar/find_matches, I just need
+  to assign the X,Y value from the incoming star data.  For loading
+  old catalogs which don't include X,Y in the table, I need to
+  calculate the X,Y position based on the R,D after finding the
+  matching image.  I have code to do this calculation currently in
+  dvo/photometry.c for looking up X,Y on the fly.  once this is moved
+  into the load functions, it will not be needed in photometry.c
+
+- remove PRI/SEC and only use secfilt table for mags
+
+  this is not a very difficult change, conceptually, but it may be a
+  fair amount of work.  all of the functions which currently switch on
+  the case of PRI/SEC just need to look in the secfilt location.  the
+  value of Nsec needs to increase by 1.  the load from tables which
+  used PRI/SEC need to move the PRI values to the correct location in
+  secfilt
+
+  eventually, rename 'secfilt' to a better name choice
+
+- add image, average, measure IDs
+
+  for PS1, the image and measure need to be generated by the external
+  software.  they would just be part of the input stream.  for the
+  case were the IDs are not supplied, DVO needs to generate them in a
+  unique way.  I probably need to understand / define that mechanism
+  before tackling this problem.
+
+  one point: I need to keep the old averef index.  how do this index
+  and the objID work together?
+
+- link measure to image
+
+  temporariliy use an index like averef?
+
+- move photcode table to catdir (also zero points)
+
+  should be fairly easy: just like the SkyTable, look in the catdir
+  first, then generate from the default text table if it is missing.
+
+- color term as a function of mosaic position
+ 
+- mextract field,field,field 
+
+  this should not be a very difficult job.  just add a loop to the
+  avextract / mextract functions.
+
+- mextract field(s) where condition
+
+  this is a bit trickier, and could make use of the code in the dvo
+  math functions
+
+- dvo select from mysql
+
+  not very difficult: need to define the commands to select the
+  database and set up a connection, then parse the select line into
+  the appropriate format.  just need to as the db for the type of the
+  fields that are requested: must be numerical.
+
+  select field,field,field from table where condition
+
+- change vectors to doubles
+
+  probably not a terrible job.  this will depend on how the union is
+  defined.  I don't want this to explode the size of an image!
+
+---------
 
 I now have the ability to load and save DVO databases in old formats,
@@ -12,10 +86,11 @@
 - CFHT Elixir databases: cmp files, ELIXIR format
 - Brandon's Taurus db: incorrect 'PANSTARRS' format, should be called
-  'PSTEST1'
+  'PSTEST1'.  drop support for this eventually? have brandon migrate to
+  the new panstarrs formats?
 
 I am going to use the following naming convention for future db table
 updates:
 
-- PANSTARRS.DEV.0
+- PANSTARRS.DEV.0, PANSTARRS.DEV.1, etc
 - PANSTARRS.PS1.0, PANSTARRS.PS1.1, etc
 - PANSTARRS.PS4.0, PANSTARRS.PS4.1, etc