You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Temporal attributes: HistoricalLocation, Sampling, PreparationStep have a time attribute, Deployment a more specific deploymentTime attribute. Suggest to either name all temporal attributes directly related to the containing class as "time" (easier to handle but less explicit) or add entity name to time attributes such as in deploymentTime (e.g. samplingTime)
Spatial attributes: Location.location, FeatureOfInterest.feature are of data type GeoJSON, Datastream.observedArea, Sampling.samplingLocation a Geometry. Is there a specific reason for this distinction? Also consider renaming Sampling.samplingLocation to Sampling.location to be consistent with Location.location (same as with temporal attributes)?
Datastream.observationType is defined as a String but according to OMS (AbstractObservationType) this is rather a CodeList. In terms of interoperability, wouldn't it be better to enforce or recommend a code list depending of the contained observation result types?
depthUom in Deployment and Sampling defined as String, unitOfMeasurement in Datastream as dedicated data type UnitOfMeasurement. Better to align?
The current FROST WQ data model has a couple of naming inconsistencies:
Temporal attributes: HistoricalLocation, Sampling, PreparationStep have a time attribute, Deployment a more specific deploymentTime attribute. Suggest to either name all temporal attributes directly related to the containing class as "time" (easier to handle but less explicit) or add entity name to time attributes such as in deploymentTime (e.g. samplingTime)
Spatial attributes: Location.location, FeatureOfInterest.feature are of data type GeoJSON, Datastream.observedArea, Sampling.samplingLocation a Geometry. Is there a specific reason for this distinction? Also consider renaming Sampling.samplingLocation to Sampling.location to be consistent with Location.location (same as with temporal attributes)?
Datastream.observationType is defined as a String but according to OMS (AbstractObservationType) this is rather a CodeList. In terms of interoperability, wouldn't it be better to enforce or recommend a code list depending of the contained observation result types?
depthUom in Deployment and Sampling defined as String, unitOfMeasurement in Datastream as dedicated data type UnitOfMeasurement. Better to align?