Open knelson-farmbeltnorth opened 2 years ago
I created a new polymorphic type called "Value" that is one of Numeric Value, Enumeration Member or String and placed this type on the Logged Variable Value (f/k/a Working Data Value). Since the Logged Variable Value requires a reference to a Logged Variable that itself requires a Representation, there is no need for any reference to the Representation on the actual value, and thus this new type.
For self-describing values (in Summary Value and [Reference Layer] Spatial Attribute), I used the term "Representation Value" to make it clear that it requires a polymorphic Representation Value vs. a polymorphic Value.
Accepted in Sept 28, 2022 meeting
Today the SpatialRecord refers to a list of RepresentationValues, themselves referring to Representations. In addition, SpatialRecords are tied to WorkingData objects, each of which contains a Representation, and in the case of NumericWorkingData, a Unit of Measure (object).
Since the working data defines both the Representation and the Unit Of Measure where required, the Spatial Record should not duplicate this information (often 1000s of times per OperationData). It may suffice to have the SpatialRecord refer to a collection of simple objects that contain a required reference to the WorkingData, and depending on the type of Representation in that object, data in one of an int (enumerated), string (string) or double (numeric) property.
Thus one proposal: Spatial Record -Working Data Values --Working Data Id (int, required) --EnumerationValue (int, optional) --StringValue (string, optional) --NumericValue (double, optional)
The WorkingData should carry a full reference to the Representation since we allow for user-defined Representations and a code will not suffice. Per #61, a unit code should suffice on all objects.