OBGenericData Class Reference

#include <openbabel/generic.h>

Inheritance diagram for OBGenericData:

Detailed Description

OBGenericData is an abstract base class which defines an interface for storage, retrieval, and indexing of arbitrary generic data. Subclasses of OBGenericData can be used to store custom data on a per-atom, per-bond, per-molecule, or per-residue basis. Open Babel currently supports a small subset of chemical functionality as OBGenericData types, which will expand over time to support additional interconversion (e.g., spectroscopy, dynamics, surfaces...)

For more information on currently supported types, please see the developer wiki: http://openbabel.sourceforge.net/wiki/Generic_Data

For your own custom data, either define a custom subclass using an id from the OBGenericDataType::CustomData0 to OBGenericDataType::CustomData15 slots, or store your data as a string and use OBPairData for key/value access. The latter is highly recommended for various text descriptors e.g., in QSAR, atom or bond labels, or other textual data.

New in Open Babel, version 2.1 is the template-based OBPairTemplate, which can be used to store arbitrary data types. There are predefined types OBPairInteger and OBPairFloatingPoint for storing integers and floating-point values without converting to a string representation.

Also new is the "source" or "origin" of a data entry, enumerated by DataOrigin. This can be accessed by SetOrigin() and GetOrigin(), as well as via "filtering" methods in OBBase, allowing you to separate data read in from a file, added by a user, or assigned by Open Babel internally.

While the library and import routines will set DataOrigin correctly, you should try to annotate data added by your code. Typically this would either be userAdded or external. The former refers to something the user requested as an annotation, while the latter refers to annotations your code adds automatically.

Example code using OBGenericData:

      if (mol.HasData(OBGenericDataType::UnitCell))
      {
         uc = (OBUnitCell*)mol.GetData(OBGenericDataType::UnitCell);
         sprintf(buffer,
            "%10.5f%10.5f%10.5f%10.5f%10.5f%10.5f",
            uc->GetA(), uc->GetB(), uc->GetC(),
            uc->GetAlpha() , uc->GetBeta(), uc->GetGamma());
         ofs << buffer << endl;
      }

      ...

      vector<OBGenericData*>::iterator k;
      vector<OBGenericData*> vdata = mol.GetData();
      for (k = vdata.begin();k != vdata.end();++k)
         if ((*k)->GetDataType() == OBGenericDataType::PairData)
         {
            ofs << ">  <" << (*k)->GetAttribute() << ">" << endl;
            ofs << ((OBPairData*)(*k))->GetValue() << endl << endl;
         }

Similar code also works for OBGenericData stored in an OBAtom or OBBond or OBResidue. These examples show use of DataOrigin outside of the Open Babel library.

      string atomLabel; // e.g., from the user adding annotation to an atom
      if (!atom.HasData("UserLabel")) // stored textual data as an OBPairData
      {
         OBPairData *label = new OBPairData;
         label->SetAttribute("UserLabel");
         label->SetValue(atomLabel);
         label->SetOrigin(userInput); // set by user, not by Open Babel

         atom.SetData(label);
      }

      ...

      if (bond.HasData("DisplayType")) // e.g. in a visualization tool
      {
         OBPairData *display = dynamic_cast<OBPairData *> bond.GetData("DisplayType");
         if (display->GetValue() == "wireframe")
         {
            ... // display a wireframe view
         }
      }

When designing a class derived from OBGenericData you must add a Clone() function. For classes used with OBMol this is used when an OBMol object is copied. If your class member variables contain pointers to atoms or bonds then it will be necessary to ensure that these are updated in Clone() to refer to the new molecule. Without these and similar pointers it is more likely that the very simple clone function

      virtual OBGenericData* Clone(OBBase* parent) const
         {return new MyNewClass(*this);}

It is recommended that, if possible, OBGenericData classes do not store atom and bond pointers. Using atom and bond indices instead would allow the simple version of Clone() above. See OBRotameterData::Clone for an example of a more complicated version. For classes which are not intended to support copying, Clone() can return NULL

      virtual OBGenericData* Clone(OBBase* parent) const 
         {return NULL;}

Constructor & Destructor Documentation

Member Function Documentation

Member Data Documentation

• generic.h
• generic.cpp

---

This file is part of the documentation for Open Babel, version 2.1.0.

Documentation copyright © 1998-2007, the Open Babel Developers.
Open Babel is hosted by:
Generated on Tue Apr 24 18:08:15 2007 by  1.5.2.