Spatial Data Scoping Issues

[knelson-farmbeltnorth]

There are several changes necessary in the Spatial Data elements.

CalibrationFactors are currently on LoggedData, but (necessarily) refer to a Logged Variable Id. Since these are scoped to individual Operation Data elements, the Calibration Factors should be on the Operation Data. This also follows for cases where a LoggedData has multiple OperationData elements for separate components of single pass applications.

Summary Value (f/k/a Metered Value) has a Logged Variable Id, likely to map to the ISOXML Data Log Value object. However, within ADAPT Summary Values are stored separately from the LoggedData/OperationData, so the Logged Variable will not be traceable without crawling the entire Logged Data tree. If we want to persist this mapping, we should add a Logged Data Id, OperationData Id, and DeviceElementUse Id in addition to Logged Variable Id. The consumer can then map directly to the specific variable.

Device Element Uses has been a property on Documents, but seems to be an error, perhaps due to earlier acknowledgement that it will not be possible to map to ids in the spatial data. If we follow the pattern for Summary Values above, this should not be necessary. Device Element Use has an OperationDataId property that should be removed for similar reasons.

[knelson-farmbeltnorth]

Agreement in Oct 5 2022 meeting

[knelson-farmbeltnorth]

Per the decisions made in #70, we won't provide all ids in the hierarchical mapping down to, e.g., SummaryValue.LoggedVariableId. Implementers can create indexes as may be needed to avoid crawling the hierarchy repeatedly, and this is a separate consideration from the data model.