oh, and do we want to keep a "user parameters" vector in here so that things can be kept WITH the geometry? or is it better as I said below, that they have their own specialized object...

25 MAY 2007: Thoughts so far...

First attempt. Since I heard nothing back regarding the previous thoughts... :-)... I did the following. However, it wasn't what I was GOING to do. I jumped ahead to a full reco-geometry instead of just the numbering. I will back off of this effort and work on just the detId to DDD mapping.

#ifndef GUARD_RecoObjects_H
#define GUARD_RecoObjects_H

#include 

/** @class
 *
 *  @author:  Michael Case               Initial Version
 *  @version: 0.0
 *  @date:    21 May 2007
 *
 *  Description:
 *
 *
 *
 */

class RecoGeom {

 public:

  RecoGeom() {  }

  RecoGeom ( uint32_t detId
             , const std::vector& trans
             , const std::vector& rotmat
             , const int& shapeType
             , const std::vector& pars)
    : pDetId(detId), pTrans(trans), pRotMat(rotmat), pShapeType(shapeType), pPars(pars)
    {   }

  ~RecoGeom() { }

  uint32_t pDetId;
  std::vector pTrans;
  std::vector pRotMat;
  int pShapeType;
  std::vector pPars;
};

class RecoIdealGeometry {
 public:
  std::vector pRecoGeom;
};

#endif

And in order to have an example I looked at the CSC code with which I am more familiar.

1. I had to create a class CSCGeometryParsFromDD which essentially is CSCGeometryBuilderFromDDD but the build() method does not build a CSCGeometry and it simply keeps the DD "raw" parameters for each det that would have been created.
2. The fupars (user parameters) are NOT saved in this "generic reco geometry" class, a different conditions object should be created for these. Right now, some of these are could be considered geometry information that are attached using SWGuideSpecPars, such as the distance from the alignment pin to the first wire. However, I assumed that these would be kept in another persistent class just and mapped to these parts via the detId as well.
3. I put in the whole rotation matrix, all 9 numbers.
4. I have the prototype working to store the information and currently put it in an sqlite file. I will have to write a CSCGeometryBuilderFromDB or Conditions or something like that, or someone else will have to do so.

16 MAY 2007: Thoughts so far...

Reco selects out certain parts in the hierarchy of the DD as being important for reconstruction and tracking. To these parts they assign an id and retrieve from the DD the numbers needed to make "bound planes" [whatever they are :-)] and information to convert from local to global coordinates. The filters of the DD are used to select these parts and there is sub-detector specific code that construct the reco geometry using these filters.

An alternative is to store this information such that reco can build its geometry from non-DD sources [i.e. the conditions system]. For example, a CSCGeometryBuilderFromDDD would be replaced by CSCGeometryBuilderFromDB or some such name.

What we need.

1. Tool [cmssw analyzer] that reads in the XML and outputs the det id to a conditions object.
2. At least one example on how to get the conditions object so that sub-det specialists can write the builder from db code.
3. Validation tool to compare between XML input and DB in conditions. NOT sub-detector specific, only compares geoHistory() to DB detID match up.

Questions:

1. What do we store from the XML?
2. What do we store from the Reco geometry?
3. Have I missed anything?

Solutions:

Answer to 1: Provide one object for cross-reference. This contains a long string showing the DD's geoHistory() output of a node, the det id, and MAYBE the nav_type [though I don't trust that because nav_type = geoHistory() between different versions, but geoHistory() always should be consistent with other version regardless of order of building the DD]. ASSUMPTION 1: this will only be used for validating and checking that a DB is consistent with a given set of XML files.

Answer to 2: Provide one object that contains the det id, position and numbers for the bound plane (i.e. shape parameters). ASSUMPTION 2: While traversing reco geometry one can get at the shape parameters and positions.

Answer to 3: from outside, hopefully SOMEONE will read this!

-- MichaelCase - 16 May 2007