この記事では、より高度な質問に答え、データ品質を向上させるために重力ベースのネットワークに適用できるいくつかの高度な構成について検討します。ユーティリティネットワークがサブネットワーク、端末、およびルールの使用を通じてこれらの課題にどのように対処しているかを見ていきます。
すべてが接続されていますか？
システム内の流れの方向を特定するためにトレースを実行できることは有用な分析ツールですが、よくある質問はすべてのフィーチャが適切に接続されているかどうかです。これを判断する最も簡単で効率の悪い方法は、マップにトレース位置を配置し、接続トレースを実行することです。このトレースは、その位置まで移動可能なすべてのフィーチャを特定します。これはすべてが接続されている小規模なネットワークにはうまく機能しますが、データセットが非常に大きい場合、このトレースにはより多くの時間がかかり、データが単一の接続されたシステムにすべて接続されていない場合は、ネットワーク全体をカバーするために複数の開始位置を提供する必要があります。
以下はストームウォーターデータセットの例です。集水域のみがモデル化されており、それらを接続する川やチャネルはモデル化されていないため、単一の接続トレースでは切断されたフィーチャを特定できません。
ユーティリティネットワークが切断されたフィーチャを特定するのに役立つ方法の一つはサブネットワークの構成です。サブネットワークは、特定エリア内のリソース制御を担当するデバイス群とともにユーティリティネットワークの名前付きサブセットを表します。ストームウォーターネットワークの場合、これは通常各集水域を制御する排水口です。
もし集水域のすべての排水口をサブネットワークコントローラーに変えた場合、ネットワークに接続されているすべてを見つけるためにトレースを実行できます。これはネットワーク内の各排水口を開始位置として接続トレースを実行することでシミュレートできます。
もし「Stormwater System」という単一サブネットワークを作成し、それぞれのデバイスをサブネットワークコントローラーとした場合、上記グラフィックで選択されたフィーチャがそのサブネットワークになります。これは初期品質保証の観点から有用ですが、各エリアを支配する排水口群それぞれを特定集水域用コントローラーとしてモデル化するとさらに有用です。GISデータに依存して計画や工学モデルを維持する技術者は既にGIS外でこの情報を追跡しています。GIS内で集水域をモデル化することで、変更が位相的に正しいだけでなく、技術者や計画者がモデル作成に必要とする情報も検証できます。
保持しているデータの品質、複雑さ、および量によっては、システム全体で単一サブネットワークのみモデル化することもあれば、それぞれの集水域ごとに別々のサブネットワークを作成することもあります。ここでは別々のサブネットワーク構成というより難しいタスクについて説明します。この手順はMigrate to Utility Networkツール実行時に1つ以上のレイヤーでコントローラーが識別されたことを前提としています。そうでない場合はフィーチャがサブネットワークコントローラーになるため追加構成が必要です。
ルールと端末
デフォルトではMigrate to Utility Networkツールはシンクベースネットワーク内でサブネットワークコントローラーがUpstream端末のみでフィーチャと接続するよう構成します。排水口下流側をモデル化していない場合は次節でサブネットワークコントローラー作成方法をご覧ください。
最初に行うべきことはネットワークプロパティダイアログでルールを確認することです。以下は排出ポイント用ルールの一部です。よく見ると排出ポイントは上流端末でモデル内すべてのタイプラインと接続するよう構成されています。
これらルールは排出ポイントが他フィーチャとどのようにつながるべきかより正確に反映するよう洗練できます。
- Outfall - これらフィーチャはパイプが開放排水路へ排出できるようにします
- Overflow - これらフィーチャはパイプまたは仮想排水路線が開放排水路へ溢れることを許可します
- Standard Outlet - これらフィーチャはパイプが仮想排水路線へ排出できるようにします
- Terminal Discharge - これらフィーチャはパイプまたは開放排水路がシステムから出ることを許可します
Add RuleおよびDelete Ruleツールでルール設定し直し後、ネットワーク位相有効化すると多くの排出ポイントで接続エラー（下図赤線）がデータベース内に現れる可能性があります。
データやルール調整によって2種類異なるエラーが見られます：無効な接続性 - 2つフィーチャ間接続許可ルールなし。
曖昧な接続性 - 複数ルールでフィーチャ間接続許可あり。
個別エラー確認・修正も可能ですがエラー多数の場合Analyze Network Dataツール利用し全エラータイプ概要取得した方が効率的です。
エラー確認用レイヤーファイル作成以外にもRuleCandidates.csvファイル出力されます。このファイルには接続エラー解決可能な追加ルール候補含まれます。インポート前によく確認し、本当に接続許可すべきフィーチャ用ルールのみインポートしてください。技術者や現場作業者と相談し適切判断必要な場合があります。このプロセス詳細はRefining connectivity rule記事をご覧ください。
追加ルール決定後Import Rulesツール使いユーティリティネットワークへ追加してください。ただし追加前には必ずネットワーク位相無効化してください。
不足ルール追加後再度位相有効化したらModify Terminal Connectionsツール使い曖昧な接続性解消してください。この操作は1つラインが複数端末へ接続許可されている場合のみ必要です。
この種接続エラー対処例もっと知りたい場合、以下3つチュートリアルで意思決定過程案内しています：Editing and connectivity ラーニングシリーズです。
ネットワーク位相有効かつエラーなしになったら次はサブネットワーク作成準備完了です。
簡単なサブネットワーク作成
まず各集水域用サブネットワークコントローラーとして機能する排水口特定します。これはネットワーク内ある範囲で接続トレース実行し、サブネットワークコントローラーとして設定済み排水口到達時停止させることで可能です。手動選択・バリア追加もできますが条件バリア使い自動識別した方が楽です。そのためCategory属性値Subnetwork Controller持つフィーチャへ条件バリア追加します。
これにより資産タイプCategory属性値Subnetwork Controller（ここでは排水口）持つ任意フィーチャ到達時トレース停止します。このNetwork Category属性値はMigrate to Utility Networkツール実行時コントローラーマッピング指定部分から初期設定されます。またSet Network Categoryツール使い後から調整可能です。このトレース結果例は以下参照ください。
この例では単一排水口へすべて接続された範囲があります。Modify Subnetwork Controllerツール使い排水口上流端末（材料受け入れ側）へ新しい集水域用サブネットワークコントローラー設定してください。このコントローラーには固有名付与し、この範囲にも固有名付与必要です。他部門との協議で既存識別子利用希望あればそれ使用すると連携・コミュニケーション円滑になります。
変更検証後、この排水口へ接続されたすべてフィーチャを見るためサブネットワークトレース実行可能です。
Update Subnetworkツール使いこれらフィーチャへ集水域名保存もできます。この機能でどれが集水域所属か簡単判別可能になります。
このツール実行後、このサブネットワーク内すべてフィーチャへサブネットワーク名設定されました。
またこの集水域内すべてライン表現したサブネットワークリン特徴示されています。
Update Subnetworkツール使いサブネットワークリン特徴作成後、そのライン現在範囲内ならFind Subnetworkペインへ表示されます。
単一コントローラーによる簡単なサブネットワーク作成方法理解したので次に複数排水口ある集水域対応方法見てみましょう。
複数コントローラーあるサブネットワーク
すべてのサブネットワークが単一コントローラーとは限りません。ストームウォーターネットワークでは状況によって複数排水口が同じ集水域から放流責任負うことがあります。
手順開始方法は同じく、ネットワーク内で接続トレース実行しサブネットワークコントローラー扱いバリア設定すると排水口到達時停止します。このトレース容易化目的でトレース構成作成・利用検討してください。
この例では3つ排水口ある集水域があります。同様手順繰り返し各排水口固有名付与します。ただし同じサブネットワーク名付与します。同じ範囲から放流責任共有しているためです。
注意: サブネットワークコントローラー名未指定の場合、自動的にフィーチャglobal id使用されます。
もう一度、ネットワークトポロジーを検証し、update subnetwork を実行して2番目のキャッチメントの作成を完了します。
このプロセスを繰り返して、ネットワーク内のすべてのフィーチャがサブネットワークに属するようにします。これは簡単に聞こえますが、よく起こる問題をいくつか見てみましょう。
コントローラーの欠落
このプロセスを使用すると、すべてのサブネットワークを特定するための信頼性の高い手動プロセスが提供されます。最も一般的な問題は、サブネットワークコントローラーがデータから欠落しているか、データの問題によりキャッチメントエリアが本来よりもはるかに大きく表示されることです。以下の例を見ると、本来は小さなキャッチメントエリアであるべきものがはるかに大きなエリアとして表示されていることがわかります。
上記の画像で示された領域をズームインすると、この問題はキャッチメントのパイプと排水先の開放チャネルとの間にアウトフォールがないことに起因していることがわかります。これは以下の図で示されています。
このエラーを修正するには、エンジニアや現場作業員と協力してGISが現場に設置されているものと一致するようにします。この場合、パイプと川のチャネルの間にアウトフォールを作成します。そして、この新しいアウトフォールを3番目のキャッチメントエリアのサブネットワークコントローラーにします。
上記のスクリーンショットをよく見ると、このエリアにはまだ潜在的な問題があります。このキャッチメントの北側にあるいくつかのパイプには出口がありません。ズームインすると、このエリアはおそらくキャッチメントエリアに接続されているべきであることがわかります。これが実際にそうであるかどうかはエンジニアや現場作業員に確認する必要がありますが、一度接続方法や接続有無が判明したら、それを反映するようGISデータを更新できます。
結論
この記事では、subnetworks、rules、および terminals を使用してデータ品質を向上させる方法を学びました。これにより、欠落したフィーチャ、不適切に接続されたフィーチャ、および出口のないネットワーク内の場所を特定する方法がわかりました。watershed や sewershed の管理、sub-basins や catchments の管理など、より高度な分析タスクに興味がある場合はお知らせください！utility network に関する質問があれば、必ず Esri Community site で質問してください。
重力ベースのネットワーク（下水道や雨水データなど）を管理するために utility network を使用する方法についてもっと知りたい場合は、ぜひ Learn ArcGIS Utility Network for Sewer and Stormwater 学習シリーズをご覧ください。この学習シリーズには、utility network を使用して下水道および雨水業界のニーズに対応する方法を示すチュートリアルや記事が含まれています。
