Please note that the information contained in this article is now superceded by the article located Here
. This article will remain published to serve as a reference for the new implementation.
Please note, this document is written refering to a pre-production version of the DIGGSML schemas, things may or may not exist in the release version (specifically the "readings" tag may well change name!)
This is how we are thinking of implementing monitoring in DIGGSML, it's not set in stone, it's just one possible way of implementing Monitoring.
I'd be welcome to recieve comments (either attached to this article or via the contact facility) if you have any opinion on other ways of doing this.
Since a SamplingPoint inherits from Observation, just like Hole and FoundationGroup do, it can contain all of the common properties that are included in Observation (Geometry, CRS, Id, Name and StartDateTime are all common properties inherited from Observation) and those that are mandatory are still mandatory in SamplingPoint. A SamplingPoint contains a collection of Instruments. These instruments are the physical inspection instruments that are used to monitor.
Single Reading Instruments
A good example of a single reading instrument is a Piezometer, detecting water level, actually recording the position of the water, since ground level can move (with excavations and so on) and therefore depth (or more accurately distance down the hole from ground level) isn't necessarily a valid measurement.
Continuing our Piezometer example, a Piezometer records a number of positions, so there is a positions tag, inside which we can specify a default CRS to use when recording the individual positions within this Instrument (this will often be a reference to the CRS of the SamplingPoint itself). After you have specified the CRS to use to locate points, next you can specify the points themselves, this is done using a "readings" property, which in turn contains many PositionReading objects.
Each of these PositionReading objects defines a reading made at a point in time, so it contains the DateTime the reading was taken, and the position itself that was read, it may optionally also contain another CRS, to enable the specification of a movement in the path the reading was taken on (for example a ground level change during excavation).
Example 1 - A Single Reading Piezometer
5 <Ref xlink:href="crs_bh127"/>
6 <Ref xlink:href="crs_bh127_after_excavation"/>
Here a Piezometer is recording water level at one minute past midnight every day, the final PositionReading shows how the change in ground level on the third day means the value changes, but the actual level did not.
Multiple Reading Instruments
Multiple reading instruments are slightly different, but the only thing that differs between a multiple reading instrument and a single reading instrument is that there are many reading types reported.
They are used when the same physical instrument reads more than one thing at the same time, take an Annometer measuring wind speed and direction in the same instrument.
Example 2 - A Multiple Reading Annometer
7 <angle uom="dega">22</angle>
1 <angle uom="dega">30</angle>
5 <angle uom="dega">27</angle>
4 <velocity uom="m/s">1.34</velocity>
8 <velocity uom="m/s">0.23</velocity>
2 <velocity uom="m/s">2.9</velocity>
This Annometer example shows a single instrument (the Annometer object) recording two parameters (the directions and velocities properties) at the same time as the aforementioned Piezometer. Note how the readings themselves are independant, so you are not constrained to monitoring all of the parameters at the same time.
I hope this article helps explain how to implement monitoring in DIGGSML, Monitoring is an important part of the geotechnical framework and I hope this article shows how DIGGSML can be used to transfer monitoring data of all types in one internationally standardized way, helping systems interoperate together to the best of their abilities.