Address outstanding issues from review of version 0.9

[dazzasmith]

Address issues I reported whilst reviewing version 0.9 (too late to be addressed before public comment). I'll try and add a summary of the points here, but see also original document (with slightly more detailed descriptions) in #174.

• [ ] 1. Fig 6 under 'Catchment topology and hierarchy': Perhaps good to show a nominal representation of the catchment boundaries between B & C and BC & A.
• [ ] 2. Fig 6 under 'Catchment topology and hierarchy': catchment divide between B and C shouldn’t really be there?
• [x] 3. Review descriptive text in first paragraph of p22 under 'Catchment topology and hierarchy'.
• [x] 4. (Show the constraints on HY_DendriticCatchment - already done?)
• [x] 5. Review text in paragraph on p.38 referring to Figure 12 (see two comments in document).
• [x] 6. Review text in first paragraph of 6.5.1 Indirect position (see comments in document).

[dblodgett-usgs]

@dazzasmith - Looking at figure 6, I've interpreted your suggestions and added a bit of my own editorial, does this seem right?

• [ ] Figure 6b - add catchment boundary line as in other figures, but use a dotted style to imply a "virtual" or "nominal" catchment boundary. Also add label for C, illustrating two catchments that would be related with a conjoint association. Also add minor flowpaths that connect flowpaths n4-n2 and n3-n2.
• [ ] Figure 6c - put catchment line on top of blue polygon (waterbody) with a dotted representation to imply a "virtual" or "nominal" catchment boundary.
• [ ] Figure 6e - Suggestion to remove boundary between catchment B and C. The point here is that we can ignore complex junctions, my preference is to keep the boundary.
• [ ] Figure 6f - Add boundary between catchment B and C this was not intended to be a conjoint catchment example.

New Caption: Figure 6: Catchment connectivity examples (top left to bottom right): a) Simple catchments with one inflow and one outflow each; b) conjoint catchments with an ambiguous divide flowing into a single downstream catchment; c) catchments joining in a water body or wetland with no clear network at their shared nexus; d) catchments joining through intermittent or subsurface flows; e) catchments that join through areas of complex or braided channels with an ambiguous divide near their junction; f) catchments with distributary hydro nexuses such as in a delta.

[dblodgett-usgs]

The text accompanying figure 12 has been updated using @dazzasmith's comments in #174 as guidance.

[dblodgett-usgs]

(old) section 6.5.1 comments from #174 are no longer relevant as (new) section 6.6.1 has been reworked considerably. I'd appreciate another round of review from @dazzasmith to see if the new wording and description looks alright.

[dazzasmith]

Thanks David, I'll review the changes later today.

[dazzasmith]

Figure 12 first: Happy with the addition 'Some implementations could go even further, eliminating node n2 and lumping catchment D into X as well.'.

However, I noticed something else in the paragraph above that didn't seem right: 'Figure 12a illustrates a case where hydro nexus nodes n2 and n3 have one and two contributing catchments respectively, and both have to receiving catchments.' - Both have two? I read it that only n3 has two, while n2 has just a single receiving catchment (B) right?

[dblodgett-usgs]

That is both a type, "to" should be "two", and poorly described.

Maybe something like: Figure 12a illustrates a case where hydro nexus nodes n2 and n3 have two contributing catchments respectively, and assuming the direction of flow in catchment E is from node n3 toward n2, then n3 has two receiving catchments and n2 has one.

[dazzasmith]

Figure 6: I'm afraid I'm still having trouble with this: I find B as an example of when a ‘conjoint’ catchment would be used to be confusing. I expect to see something like the streams that are present in E to be in B i.e. providing a reason for merging catchments B+C and treating them as a conjoint catchmnent for the purpose of encapsulation (since the boundary is too complex to define). I therefore propose dropping Figure 6.B and then removing the catchment boundary between B & C in Figure 6.E and using that instead as the example of a conjoint catchment. Thoughts @rob-metalinkage @IrinaDornblut @dblodgett-usgs ...?

[dblodgett-usgs]

For B, My suggested change (which isn't applied to this graphic), is "Also add minor flowpaths that connect flowpaths n4-n2 and n3-n2.".

I'd like to do that and keep E as an example of complex junction.

[dazzasmith]

Happy with the proposed change to text for figure 12 - now makes perfect sense!

The suggestion for figure 6 B - do you mean alternate minor flow paths that connect directly between n4-n2 and n3-n2 without interacting with each other? If so, this could still happily be represented without the need for a conjoint catchment as two catchments (like A&B). How about a single minor stream connecting the two flow paths somewhere along their lengths. Or I am missing something here perhaps?

[dblodgett-usgs]

When I said n4-n2 or n3-n2, I meant the flowlines themselves, not the nodes. So I intended something like a single minor stream connecting the two flow paths, yeah.

[dazzasmith]

Cool, then that'd work for me :-) BTW, sorry that you had to repeat yourself, I just noticed that was what you proposed above. Happy with your interpretations of my comments for 6c, 6e & 6f.

[rob-metalinkage]

I dont necesarily see the probkem. For B there may be umapped or highly seasonal streams or even an extensive wetland.. these are all abstracted models anyway.

The issue is whether we can both support both choices and be able to distinguish what choices have been made.

On 23 May 2017 5:50 AM, "dazzasmith" notifications@github.com wrote:

Cool, then that'd work for me :-) BTW, sorry that you had to repeat yourself, I just noticed that was what you proposed above. Happy with your interpretations of my comments for 6c, 6e & 6f.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/HY_Features/issues/185#issuecomment-303201864, or mute the thread https://github.com/notifications/unsubscribe-auth/AIR3YeQhsznwtJ2LcZj2IWuvEEpA5X90ks5r8ecDgaJpZM4MK6f2 .

[dazzasmith]

Thanks Rob, I guess I was just concerned with making it easier on the reader. I appreciate that there can be other details as the reason that you'd want to make B conjoint, but thinking of someone new to this, when they look at B they see the same stream network as A and wonder, hmm, why would I treat B differently to A?

[dblodgett-usgs]

Summarizing for @mwernimont. I've tried to mark up the graphic with example lines (in red). You should have the original graphic file for this? Let me know if you have questions. I'll try and get ahold of you on chat to clarify anything if needed.

The changes are described as:

• Figure 6b - add catchment boundary line as in other figures, but use a dotted style to imply a "virtual" or "nominal" catchment boundary. Also add label for C, illustrating two catchments that would be related with a conjoint association. Also add minor flowpaths that connect flowpaths n4-n2 and n3-n2.
  • Figure 6c - put catchment line on top of blue polygon (waterbody) with a dotted representation to imply a "virtual" or "nominal" catchment boundary.
  • Figure 6e - Suggestion to remove boundary between catchment B and C. The point here is that we can ignore complex junctions, my preference is to keep the boundary.
• Figure 6f - Add boundary between catchment B and C this was not intended to be a conjoint catchment example.

[dblodgett-usgs]

Got changes into the document.