Process Description

[mbeaufils]

This issue is dedicated to the provision of a (more) structured way to describe a process.

Not to be confused with ObservingProcedure #34 which is about listing and naming the procedures, tests, measurements that can be performed.

[mbeaufils]

@dponti and other people that would like to propose a definition of a process.
A proposal from the OGC standard SensorML exists. It worth been considered: http://docs.ogc.org/is/12-000r2/12-000r2.html

For your information, SensorML is a usual buddy for OMS ;-)

Originally posted by @mbeaufils in #34 (comment)

[mbeaufils]

Below is a proposed start at a UML model for a Geotechnical Process (GT_Process). This object is intended to be the object that is referended by the Observation's procedure property. Following I'll give some encoding examples. The intent of this model is to accommodate pretty much any kind of chain of complex procedural observations that are then used to determine the observation's "result". The process can contain a chain of "procedures" each one of which can have any number of nested "procedural observations". Metadata is handled by the parameter property, which uses OM's NamedValue object. The ProceduralObservation derives from GML's AbstractCoverage which allows for all of the 4 observation typologies we evaluated earlier within a single structure.

Note, I've looked a bit at SensoML's process structure but need to see examples of how a process chain is encoded and how the inputs and outputs work together. @mbeaufils do any examples of this exist? The examples included with the schema are pretty poor. Would be worthwhile to see if this model can be conformed to the SensorML model

Originally posted by @dponti in #34 (comment)

[mbeaufils]

Attached are encoding examples of GT_Process for a Lugeon test procedure and a Partlcle Size test procedure using the above model in JSON notation (my apologies for any screw ups as my JSON skills are poor). I'm more comfortable in XML but this might be more readable. The extra nesting is due to conformance with GML's object-property rule.
LugeionExample.txt
ParticleSizeExample.txt

Originally posted by @dponti in #34 (comment)

[Didymograptus]

Excellent, something to get to grips with. The JSON needs attention, but I can clean that up. I find that JSON is a great way to describe the data, Actually faster to develop in JSON and use that to generate the UML.

[Didymograptus]

Attached is an implementation of the LugeonExample file and associated object and UML diagram generated directly from the JSON file. I'm sure this will need to be refined significantly. I've tried to keep the nesting to a minimum for simplicity, but realise that we may need to add complexity.

LugeionExample.txt

PSD to follow.
updated the txt file- first one was incorrect.
UML added

[Didymograptus]

Attached is an implementation of the PSD example file. ad associated UML and object diagram. As above, this has been simplified to make it easier to understand and build upon

ParticleSizeExample.txt

.

[Didymograptus]

What's next with this? I suggest that we write some code to generate a simple report with graphs etc? I think that only by trying to parse the data will we understand any problems/opportunities.

[rhaener]

Just for demonstration purpose, I've compiled a process that I use for creating contour-lines from a point-cloud of depth-information regarding geological boundaries
modelling-process.example.zip
.

[rhaener]

I compiled the Liquid Limit based on the Business Process Model Notation (BPMN), which is a very powerful format to describe complex and concurrent processes. It also provides the possibility to document all facets of the process and moreover to model condition-based process-graphs. For the time being, I've attached only diagrams without further explanation. However, the should be self-explaining
Water Content.pdf
Liquid Limit.pdf
Steps 1 - 3.pdf