dgp.core.models package

The models package contains and defines the various data classes that define the logical structure of a ‘Gravity Project’

Currently we are focused exclusively on providing functionality for representing and processing an Airborne gravity survey/campaign. In future support will be added for processing and managing Marine gravity survey’s/campaigns.

The following generally describes the class hierarchy of a typical Airborne project:

AirborneProject
├── Flight
│ ├── DataSet
│ │ ├── DataFile – Gravity
│ │ ├── DataFile – Trajectory
│ │ └── DataSegment – Container (Multiple)
│ └── Gravimeter – Link
└── Gravimeter

The project can have multiple Flight, and each Flight can have 0 or more FlightLine, DataFile, and linked Gravimeter. The project can also define multiple Gravimeters, of varying type with specific configuration files assigned to each.

Model Development Principles

  • Classes in the core models should be kept as simple as possible.
  • @properties (getter/setter) are encouraged where state updates must accompany a value change
  • Otherwise, simple attributes/fields are preferred
  • Models may contain back-references (upwards in the hierarchy) only to their parent (using the ‘magic’ parent attribute) - otherwise the JSON serializer will complain.
  • Any complex functions/transformations should be handled by the model’s controller
  • Data validation should be handled by the controller, not the model.
  • A limited set of complex objects can be used and serialized in the model, support may be added as the need arises in the JSON serializer.
  • Any field defined in a model’s __dict__ or __slots__ is serialization by the ProjectEncoder, and consequently must be accepted by name (keyword argument) in the model constructor for de-serialization

dgp.core.models.project module

Project Serialization/De-Serialization Classes

dgp.core.models.meter module

New in version 0.1.0.

dgp.core.models.dataset module

New in version 0.1.0.