Aquifer Testing Discussion

We tried to see if we could implement the aquifer test (or pump test) in a pure O&M encoding. There are several requirements that need to be considered

• Test can involve more than one Well/Bore
• Test generate intermediate data (drawdown curves) from which other parameters are derived
• Some data are related to the process itself (discharge of the pump, interval of the test)
• The parameters that are infered from the test must be somehow related to GW_UnitFluidProperty, which is itself an association between a unit and the fluid body

Our first iteration gave this - it's not a model, it's a O&M pattern for aquifer testing.

• aquifertesting.png:
  

The aquifer test is modelled around a series of interelated Observations (OM_Observation can be connected to each others using relatedObservation with roles. By defining a vocabulary of roles we can connect drawdown curves and their interpreted values (and vice-versa). Wells can also be organised in a network (if required) using SamplingComplex that can link wells together. Processes provide the data about the test itself, the Process onj the observation well would document how the water elevation were measures, while the Pumping well could document other variables (such as pump discharge).

As discussed, the process should document the properties of the pump (or pumping) that is relevant to the test (and not the pump itself), unless it's a proxy for a pumping parameters. We still have to deal with "well known procedure" which is just a name and detailed procedure where parameters of the procedure are important. The process variable could be described using SensorML or *FL, or Metadata, or, alternatively directly in Observation's NamedValues

Model	Pro	Con
SensorML	formal, no need to develop something	complex
*FL	eleguant approach (ex-factory + dynamic)	not standard, about Sensor (bit streched) - see below
NamedValue	Simple	ad hoc overload of Observation parameters
Custom (develop our own)	No ambiguity, more constrained semantic	world of its own that it might be futile to attemp to define every possible cases

NamedValue, although we tend to think is a way to attach a single value to an observation, it not limited (which is good or bad -because we can come up with our own unsuspected pattern that only make sense for GWML). But NamedValue CAN contain a full DataRecord, or any other SWE data structure we can think of.

In this pattern, we don't have a class that bundles the "aquifer test", it's a group of interconnected feature. One way to bundle a complete test is to use a single SamplingFeature (or a subtype) to represent the whole aquifer test (to be discussed)

• Aquifer Test:
  

encoded instance base on Peters's example

https://xp-dev.com/svn/gwml2/Documents/instance/pumptest.xml

The instance is organised as in the diagram below. Wells themselves were not encoded as they should technically be in some data store as external resources. The wells do not have a link back to the test (as it's normally modelled in O&M where the feature of interests don't 'know' about the observation made about them. It also allow the same well to play different roles in different test as the roles are assigned (scoped) by the test itself.

-- EricBoisvert - 24 Feb 2015

Pump

Although "Pump" is an important part of the aquifer test, the real piece of information is the pumping (rate, method, etc..), not the device because there is a difference between a device capacity and its actual performance once used. When a device need to be documented, it's when it's part of the construction because we might be interested in its range of use.

*FL (Starfish Fungus Language - OGC 11-058r1) proposed two way to document a Sensor (but it could be extended to a device)

• Its ex characteristic (parameter provider by the manifacturer)
• Its dynamic characteristics (setup actually used)

It's a bit far fetched, but a Installed Pump could be modelled as *FL Sensor

Alternatively, we could duplicate the Observation (and SamplingFeature) soft property mechanism:

• Equipment.png:
  

Note : SF_SamplingFeature has a hostedProcedure property ("A common role for a spatial sampling feature is to host instruments or procedures deployed repetitively or permanently. If present, the association Platform shall link the SF_SpatialSamplingFeature to an OM_Process deployed at it. The OM_Process has the role hostedProcedure with respect to the sampling feature.") - I was not aware of this.