nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

MS4インフラを考慮したDEM由来の流路に対するArc Hydro（またはその他のツール）はありますか？

JasperRomero

皆さん、こんにちは。

Arc Hydroや水資源の分野には比較的新しく、もしこの質問の答えが明白であれば申し訳ありませんが、表面的な調査を超えて探しましたが、求めているものは見つかっていません。

私は比較的急峻な標高勾配を持つ小さな都市の小川の流路レイヤーを更新する作業をしています。現在彼らが持っているソースレイヤーは90年代にデジタイズされたもので、かなりの不正確さがあります。最新のLidar由来のDEMから、Arc ProのHydrologyツールセットを使って流向、流量蓄積を取得し、流路を作成しました。私の目標は異なる流路階級スケールで流域解析に適した正確な流路レイヤーを開発することです。

未開発地域ではDEM由来の流路は明らかに古いレイヤーより正確ですが、インフラ周辺や開発地域、都市部ではDEM由来の流路が奇妙な挙動を示し始めます。視覚的検査によると、多くの「奇妙な」流路挙動はMS4インフラが水を地表下に導き、その障害物（例えば道路など）の反対側で再び地表流路に戻す場所にあります。

Arc Hydroツールセット（または他に機能するもの）を使って、DEMベースの流路抽出処理にMS4インフラ情報を「通知」することは可能でしょうか？例えば、ストームドレインパイプの両端にある入口と出口ノードを「リンク」して、Flow Accumulationが入口下のセルに蓄積された総量を出口下のセルに加算し、Flow Directionがストームドレインパイプを流路として認識し、自動補間や道路上での迷走を防ぎ、時には実際の流路に戻るようなことなく実際の下流方向の流れを保持するような処理です。

添付画像をご覧ください。古い流路レイヤー（太字赤）、ストームドレインノードとパイプ（それぞれ緑点／黒線）、そして新たに抽出された流路（青）が接続性維持のために奇妙な自動沈下補間処理を行っています。

私の現在（限られた！）Arc Hydroツールへの理解では、それらは私が求めている方向とは逆で、つまり正確な流路が最初に必要で、それからストームドレインインフラと統合できるというものです。また完全統合されても、入口と出口に関して実際にストームドレインシステム内で「配管」された流れになるかどうかもまだ不明です。同様の効果を得るためにストームドレインパイプをDEMに「焼き込む」ことも検討していますが、それは悪い方法かもしれないと思い、他の方法について情報を探しています（もしこのアイデアが最初に思いついた時ほど賢いなら教えてください。あなたのおかげで嬉しくなります）。

この問題への解決策を概念化するための提案やリソース、例など何でも歓迎します！ご支援ありがとうございます。

追伸 - 関連して：新しい流路が道路下を通過する箇所では道路レイヤーで消去する予定ですが、新たに抽出された流路を道路エリアで消去すると、「下流」（笑）として流路終端ノードを流域解析用の排水点として使う能力が妨げられるでしょうか？まだそこまで考えておらず、ご意見いただけると大変ありがたいです！

タグ付きの投稿をもっと見る

Water Resources

Arc Hydro

Accepted answers

All comments

ChristineDartiguenave

Arc Hydro contains some tools that handle stormwater infrastructure. Basically data are considered as inlet, outlet, open channel (streams), closed pipes (pipes, culvert). The water enters a closed pipe through an inlet (sink) and leaves through outlets. Arc Hydro creates connectors for the outlets by tracing from the end of the pipes.

You can find more information on the process in the following documents:
https://www.esri.com/content/dam/esrisites/en-us/media/powerpoints/arc-hydro-for-stormwater-overview.pdf
https://www.esri.com/content/dam/esrisites/en-us/media/technical-papers/arc-hydro-stormwater-processing-pro.pdf
https://mediaspace.esri.com/media/t/1_dmcvd1i9/244549852

Note that these documents are being updated to reflect the latest changes in the tools with the use of the continuous flow method for flow direction and the addition of stream outlets to add the ability to trace from the end of open channel ditches.

Christine

JasperRomero

Hi @ChristineDartiguenave ,

Thanks so much for your reply! I've been doing more digging and learning about Arc Hydro since posting, and your suggested references look very helpful (was just working through the technical paper you linked above!). Going to spend more time going through them and then follow up here - I realize my initial post was broad, vague, and could have been better-informed by doing more homework up front, so I really appreciate your response. It's helpful to know that those documents may be more current than e.g. 2019 or 2023.

I'll be back as soon as I can make my question more concise and clear - I think I am aiming to do something that would use Arc Hydro tools, but in a different order than how they are laid out in the example below, so I will probably have to request confirmation that I have the right idea about how everything works before I get too far down that path.

I have begun to wonder whether it's taboo to merge Arc Hydro tools/workflows with generic ArcGIS Pro Hydrology tools - e.g. should I avoid bringing Flow Dir or Flow Acc layers derived from Pro's "Derive Continuous Flow" (without prior filling) into a processing workflow with Arc Hydro tools? Or is it ok to intermingle them?

Thanks again,

Jasper

ChristineDartiguenave

Arc Hydro uses generic ArcGIS Pro tools. For example, the stormwater processing tool script that you can check as an example uses the Derive Continuous Flow tool. So, you can intermingle any tool you need.

Christine

JasperRomero

Ok @ChristineDartiguenave - thanks again for your attention to my questions!

Going to try to reframe pieces of my initial question with a better understanding.

Objective:
Use existing stormwater infrastructure features (nodes and pipes) to burn channels into a DEM, so that when stream channels (surface conveyance) are derived from that burned DEM their flow follows the path enabled by storm drain infrastructure (drains, culverts, etc.) rather than being diverted by e.g. the dams formed by an elevated roadway.

Key questions:
1) Is there a way to use Trace Network, or Trace Attribute(s), to get the elevation value(s) I should burn the pipe channels to? In the image below, for example, say the outlet node is at 400ft, the topmost node is at 415ft, the leftmost node at 425ft, and the central node is at 410ft. If I simply burned the entire network to the lowest value, i.e. the outlet at 400ft, would that be enough to get flow to follow those channels? If not, is there any way to get the incremental values I would need the rasterized channel lines to have at each cell so that flow would travel "downstream" the whole way?

storm drain example.png

2) Would I need to build "fences" along the edges of these burned in channels to prevent lateral flow from skewing e.g. Flow Acc values? Given that in "reality" there is no lateral surface flow into this burned channel, because the burned channel is really a pipe and the channel was only created to get a nice "drawing" of where stream channels actually go?

For both questions, is there a programmatic way to accomplish any necessary steps? I have experience with both ModelBuilder and writing/running custom scripts with arcpy and other modules, so those and similar approaches are options - I am still struggling to understand the connectivity and flow behavior that will govern how I accomplish what I'm aiming for.

Thanks in advance for any suggestions!

ChristineDartiguenave

Is there a reason why you want to burn in the closed pipes? We usually only define the inlets to pipes as sink point with an associated sink watershed so that they attract the water and then use the pipe in the network to transport the water in the direction of the digitized line. If your input DEM is great, you may not need to burn in the streams either, but if it is not you may need to.

You can use the Stormwater Processing tool after defining the inlets and associated sink watersheds, streams, pipes and outlets (created using Create Pipe Outlet). Then run Create Stormwater Network and check the resulting trace network to view the connectivity.

Christine

JasperRomero

Thanks for your reply @ChristineDartiguenave - I want to burn the pipes because my surface channel (i.e. stream) line layer is not very accurate, so my initial intention was to derive new contiguous streams from the DEM after burning in pipes so that the DEM-derived streams would flow "through" the pipe, rather than pooling and finding some other route around the roadbed or other obstruction.

However, now I'm wondering if I didn't fully understand the behavior of some of these tools. Could you explain, or point me towards explanations for, a couple of details?

(Apologies if these are documented somewhere, but I have been digging through all the Arc Hydro resources I can find for the past few days and still do not completely understand these details. Related post here, apologies for redundancy.)

1) During the Stormwater Preprocessing and Analysis workflow, does the "Create drainage line structures representing open channels" step create DEM-derived surface channels between the pipe sections of the storm drain system? If so, this is essentially what I am trying to get at with the pipe burning: accurate surface channels that reflect the topography of the DEM. Initially I assumed that any stormwater analysis would be limited to using the initial input stream channel layer, so since my initial stream channel layer is very inaccurate I was trying to figure out a way to get a better one that reflected the presence of subsurface conveyance (pipes).

2) Does the stormwater system created through the Stormwater Processing workflow have accurate stream delineation and stream order assignments that are not thrown off by passage through pipes or pipe networks? e.g. if a 3rd order stream enters a pipe, does the output of that pipe retain its initial stream order? Put another way, could you expand on what you mean by "use the pipe in the network to transport the water"? What is transported through the pipe network - info about flow accumulation, stream order, etc., at the inlet?

One of the end goals of my process is to be able to develop watersheds based on stream order, so I am hoping there is a way to delineate watersheds or maintain stream order classification even when surface channel systems sometimes travel through the subsurface.

Thanks again for your help! Please let me know if these questions make sense.

ChristineDartiguenave

Currently we have a tool called Assign River Order in Arc Hydro that allows assigning Stream Order to features but it works on a single feature class. So you would need to merge the streams and pipes into one layer and make sure you only have one segment between confluences to be able to use it.

Here is an example of the stormwater process. Pipes are in green and in this example streaminit is the initial stream layer that was burnt in through reconditioning since the input DEM was not "perfect". The inlet to the pipe is a sink. When tracing from the surface, you can see that the flow in yellow ends in the sink point (HydroJunction). When we do a delineation we trace through the network of both pipes and streams to add upstream contribution. We do not burn in pipes since they do not impact the surface flow.

Christine

JasperRomero

Hi @ChristineDartiguenave ,

I feel like I am not articulating my questions very well - thanks for continuing to try to assist.

I think my scenario is the inverse of the example you shared above:

1) My initial stream channel layer is the imperfect piece of data; I am trying to use Arc Hydro to acquire a more perfect stream channel layer (the original surface channel layer is at least 30 years old and diverges from more contemporary DEMs/topography significantly in many places). I am assuming that my pipes, inlets, and DEM are correct.

2) If, for example, I had an accurate network consisting of subsurface conveyance (pipes) and inlets - but did not include any surface conveyance channels at all - would the stormwater processing workflow be able to derive topographically accurate segments of surface channels between the subnetworks of subsurface conveyance? And if so, would these segments of surface channel preserve connectivity and other attributes (e.g. stream order) from the inlet(s) of a pipe network to the outlet? If I am understanding your previous post it would, with the caveat of limiting to one convergence of surface channels between each segment of pipe network.

This is why I was initially asking about burning in the pipes - my thought was that I could burn in the pipes in order to then use basic channel derivation on the burned DEM to get accurate, contiguous surface stream channels that continue to flow downstream through culverts and storm drains, whereas without burning the pipes in these channels would have to find ways around the obstructions (e.g. elevated road beds with culverts underneath).

Do these questions make sense?

Thank you!

会話に参加する

サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。

クイックリンク

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.