Determine roll and purpose of HY_Contour.

[dblodgett-usgs]

Started discussion in SWG call, need to continue the discussion about why it is a subclass of flowpath.

[IrinaDornblut]

Concept idea of contour and contour line:

a) intention is to conceptualize a 'polygon-like' linear catchment realization (edge) between inflow (node) and outflow (node) existing 'simultanuously' to an existing flowpath realization (edge), and geometrically represented by a pair of lines connected at inflow point and at outflow point. – b) contour line is understood as topological feature realization of the catchment between inflow and outflow (geometric representation: composite (pair) of two curves). - idea of homotopic lines: a contour line has the same inflow node and the same outflow node as the accompanied flowpath. - it may be understood as a flowpath deformed between fixed ends, like a 'skipping rope'. - usually, contour lines exist pair-wise. thus 'collapsing' (or much better snapping) at both ends the fixed nodes (of the two contourlines) into one on the contour-line, the representing curves may be closed to one without crossing the inside flowpath. c) contour is understood as the hydrologic realization of the catchment (by channel, depression, waterbody, stratum) using the topological realization (here: contour line) - defined in constraints to assign the contour line to the channel, depression or water body, each part of the flowpath network (realization) d) --> introduce separate features for contour (in channel network) and contour line (in hydrocomplex) as special catchment realisation with a related contourline (for the ‘twin’) --> associate flowpath with contourLine: [0..] contourline, associate contourLine with flowpath: [0..1] centreline e) --> associate depression with contour: [0..*] 'contour', channel inherits contour --> associate water body with contour: [0..2] 'bank', stratum is part of a water body which may have banks. f) --> defines constraints for the network elements (channel, depression, water body) like this: 'EXISTS ......Network, [then] contour, or bank, is of type HY_ContourLine

sounds reasonable?

[IrinaDornblut]

addition: contour has a [0..2] 'benchmark' association to OutfallRealisation

[dblodgett-usgs]

This is making sense to me. Curious what others think. I rolled your correction into the original comment.

[lieberjosh]

It would be helpful for me to see contour and/or contour line defined somewhere as a hydrologic term. It is going to be a significant map problem because there are already contour lines representing elevation. Contour lines as a mathematical concept represent some surface property such as elevation or head being held constant. I believe the usage here is to outline stream banks in a catchment but it's unclear what it is that is being held constant.

I suggest a drawing might help to elucidate this concept and another name might differentiate it from other concepts.

Josh

On Aug 8, 2016, at 08:11, David Blodgett notifications@github.com wrote:

This is making sense to me. Curious what others think. I rolled your correction into the original comment.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dblodgett-usgs]

The way I see it, they are lines of constant head at a given stage of a waterbody. That is, if the waterbody is stagnant (0 energy slope) they would be elevation contours. If a waterbody has some energy slope, they would be the surface slope of the shore lines. Maybe this is an overly literal / strict definition though? These kinds of concerns would likely be up to an implementer to decide about?

[lieberjosh]

We are really talking about an outline or boundary here. There is a special case where the outline of a stream or pond is also an elevation contour, but only in special cases like a kettle pond is that also a (groundwater) hydraulic head contour. Perhaps this is a flow outline. That may also correspond better with the concept of flowpath that it is being tied to. I'd remind also that a boundary line or polygon geometry can be associated to a channel or a waterbody without needing to define a separate feature concept.

Josh

On Aug 8, 2016, at 08:27, David Blodgett notifications@github.com wrote:

The way I see it, they are lines of constant head at a given stage of a waterbody. That is, if the waterbody is stagnant (0 energy slope) they would be elevation contours. If a waterbody has some energy slope, they would be the surface slope of the shore lines. Maybe this is an overly literal / strict definition though? These kinds of concerns would likely be up to an implementer to decide about?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[dblodgett-usgs]

waterbodyOutline?

I could also go a different way:

For me, this is a way to get a shape for a waterbodyStratum to complete the longitudinal/cross section waterbody container descriptions. Otherwise, we don't have a way to describe bathymetry. I'm starting to think I would prefer not to conflate this with flowline. We already have longitudinal section for channel geometry that may represent banks. I would rather just have a bathymetricContour feature type that is optionally associated with waterbodyStratum and depression.

[IrinaDornblut]

yes, I agree with this. - dry channel etc. have not a flowline, and bank is the contour in the perspective of the water body. - actually I thought about 'outline' of depression, channel, waterbody, but I didn't found a reasonable term for the 'deformed' flowpath.

bathymetricContour may fit better, but is bound the height (I think, isn't ot?) . - does the defitinion covers other properties than height. - bathymetric contour is very common in oceanography, not only I know. - so, we could use it, excluding oceans explicitely .

in the glossary are defintions for:

• contour(line): 'Line on a map indicating the locus of points at which a certain property is constant (e.g. elevation, salinity)'
• isopleth: 'Line of equal value of a function of two variables, e.g. line of equal value of a hydrological element represented as a function of two coordinates. I decided for contour and contourline to have an analogy of the hydro (contour) and the topo (contourLine) realization, but isopleth (not sure whether the function meaning fits), ... or bathymetricContour

[lieberjosh]

Yes, as we discussed with stratum, elevations and elevation contours in waterbodies are expressed two different ways. Bathymetry is always elevation of (or depth to) the lake or seabed. Thermoclines and such are defined from the water surface, and other strata may then be defined relative to the thermocline / pycnocline / halocline.

It is certainly possible to define the “zero-depth” contour bounding a lake or river at a specific stage, and that is reasonable as a contour of water depth, but the profile of a river (elevation of water surface along river) doesn’t necessarily remain the same at different stages, so the flow outline / zero-depth contour at another stage may not be a uniform difference in absolute elevation.

My feeling has been that these containing geometric lines / polygons / surfaces are properties of the waterbody or channel and not separate features. It can make it a little tricky in RDF to express what stage a particular geometry corresponds to (may need an extra reference elevation or stage property of the geometry) , although some are well known enough to define specific properties (bank-full, 10-yr, 100-yr, etc.). I’m not averse to defining separate water-edge features in case someone wants to use them, but it may be a very transient delineation in the case of flood crests.

Separately, I have been exploring ways to delineate stream channel containment (what is the maximum extent that still constitutes containment), comparing between energy balance approaches (e.g. HEC-RAS), and geometric approaches (removing the down-stream elevation trend, then flooding to determine the pour-point for given stream segment as if it were a lake or pond). The resulting surface could be defined as DEM / TIN surfaces or alternately as a set of water-edge “pseudo-contours” for different steady-state stream stages. Again, these lines, closed or open, could be dependent features of the channel but they strike me more as particular values of a geometry property.

Josh

On Aug 8, 2016, at 9:21 AM, Irina Dornblut notifications@github.com wrote:

yes, I agree with this. - dry channel etc. have not a flowline, and bank is the contour in the perspective of the water body. - actually I thought about 'outline' of depression, channel, waterbody, but I didn't found a reasonable term for the 'deformed' flowpath.

bathymetricContour may fit better, but is bound the height (I think, isn't ot?) . - does the defitinion covers other properties than height. - bathymetric contour is very common in oceanography, not only I know. - so, we could use it, excluding oceans explicitely .

in the glossary are defintions for:

contour(line): 'Line on a map indicating the locus of points at which a certain property is constant (e.g. elevation, salinity)' isopleth: 'Line of equal value of a function of two variables, e.g. line of equal value of a hydrological element represented as a function of two coordinates. I decided for contour and contourline to have an analogy of the hydro (contour) and the topo (contourLine) realization, but isopleth (not sure whether the function meaning fits), ... or bathymetricContour — You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/HY_Features/issues/140#issuecomment-238233003, or mute the thread https://github.com/notifications/unsubscribe-auth/AExWhiNaoQilFiOOsL-UuXyIZSXSlo3Tks5qdy1RgaJpZM4Jcve8.

[IrinaDornblut]

actually the idea of hyf to provide a referencable concept to which data products (as 'snapshots' ) describing properties may refer. thus, we need a general concept (e.g. contour) to which such a snapshot of a conceptual 'contourline' realizing a common 'contour' concept of the channel or water body (realising ultimately the catchment), can be mapped. - I like the idea of stratum as the 'lid' of the container, and if we can conclusively apply the elevation concept to any kind of stratum, we may use 'bathymetricContour', and leave to an implementation to specify the concept in some way. -

alternatively, more thinking about the stratum as the 'lid' of the container: the stratum in the perspective of the container is the confined water body (at least one layer) --> we could use the stratum feature (already associated with water body, and newly with depression) instead of contour. the 'confinedWaterBody' may be of an more general HY_IsoLine type (realizing the catchment like flowpath) under the constraint that the surfaceNetwork exists, and the 'stratum' when the 'hydrogrgaphicNetwork' exists.

could work, I think. - needs consolidation Irina

[IrinaDornblut]

depression - waterBodyStratum - watersEdge realization

The water body associates (horizontal) stratum, and vertical sections as before. The depression (new) associates a confinedWaterBody of type HY_WaterBodyStratum; channel inherits from depression and carries the vertical sections as before. There is no interaction defined between the stratum and vertical sections at the hydro level. The relation between water body and channel still exists.

This keeps the separation concerning dry and wet, and allows that depression, channel and water body may realize the catchment using as 'polygon-like' linear catchment realization HY_WatersEdge. (not used the term ‘waterBodyOutline’ since a channel represented by contours does not outline a water body; ‘watersedge’ refers to both: dry and wet part.) HY_WatersEdge (defined in the HydroFeature core) specializes the CatchmentRealisation type as feature realization of the catchment between inflow and outflow (shape: GM_Curve curve) by following the line of intersection between the water body stratum and the confining depression/channel. This line is not necessarily a contour line connecting elevation measures, but could be.

HY_WatersEdge may have a corresponding edge, allowing the create a polygon from a pair of curves at representation level, and may be part of a network built from aggregating non-overlaying edges, each single represented by a curve. via ‘watersedge’ constraints, the HY_WatersEdge type may be assigned to depression, channel or water when the …Network exists.

looks better? Irina

ps: there is a figure 'depression-stratum-edge.png' in 'reference_documents'

[dblodgett-usgs]

I am happy with this for now. The only thing I'm hung up on, although it is not a real problem, is that water_s_Edge (the s) seems a bit odd, maybe waterEdge?