UC6: "wrap" from hosted model into a borehole form

[daoane]

Maybe I do not understand correctly what is meant in the UC 6 examples, but according to the descriptions it appears to me that an item (feature/non-feature) should be taken from the hosted model and wrapped into the borehole model/"form" with positioning assigned, risking to loose context.

Is it necessary to wrap (parts of) the hosted model into a borehole form (c.f. "Examples") in order to refer to it as a feature that has a position along/is intersected by a borehole? Or is it sufficient to refer to such a feature (whatever its representation/model) externally, preferably by an unique identifier?

Example:
"borehole" (with geometry) intersects "feature defined by UID" (with geometery); positioning is implicit and can be figured out by the client as long as the hosted model is an OGC standard or equivalent.

"borehole" (with geometry) intersects "feature defined by UID" (without geometery) at depth XXXX (or: with top depth YYYY and bottom depth ZZZZ); positioning is explicit

Both examples would fulfill all three UC requirements without wrapping anything. Minimum interference with the hosted model grants maximum flexibility (as long as the hosted model is well defined and valid).

Third UC example "Exposing data that is not following OGC standard (non feature model, or maybe even under an encoding not supported by OGC)." might be problematic. If it is possible to refer to a problematic "non-feature"/"non OGC" item that is positioned along the borehole by some kind of identifier, then this approach would leave the problem where it is (i.e. with the hosted model) instead of wrapping the problem into the borehole content. However, if the only option is to wrap the item of the hosted model into the borehole content, then the question is how context can be preserved. (And if it makes sense at all to do it).

[denevers]

It's a modularity use case. It would be great if feature from any domain model could be used in a borehole context. Our immediate example was GWML versus GeoSciML. They both have different pattern to describe a log. GeoSciML uses the concept of "Interval" with a from/to AND a geometry (any geometry, but should normally be a LineString). GWML uses a coverage. They are both valid, but use different model. This addresses borehole -> domain feature (and your UID is an example), but does not address the reverse associatio (ie, Domain Feature -> borehole, in case you want to locate a sample in a borehole from the sample perspective). Observation and SamplingFeatures (from O&M) already have a way to link back to a borehole (though om:featureOfInterest and sf:relatedSamplingFeature), but misses the location part (this observation is in the borehole, but where ?). This is what this uses case is about.

[sgrellet]

As per #22 and #23, this is core of what we did in the IE (BhML inspired by ISO 19148). Good material for the ER

[sgrellet]

"This addresses borehole -> domain feature (and your UID is an example), but does not address the reverse associatio (ie, Domain Feature -> borehole, in case you want to locate a sample in a borehole from the sample perspective). "
-> read too fast, not fully addressed
-> would be solved by the approach described in #55
-> reopening