背景：ArcGIS Enterprise 11.1、ArcGIS Pro 3.1.7、Utility Network バージョン 6、現在のUN下水道スキーマは Sewer Utility Network Foundation V1.1 に基づいています。<\/P>
約18か月間本番運用しています。最近、サブネットワーク階層グループと階層を構築して新しいサブネットワークをモデル化しています。サービスエリア内の35か所のマンホールにSmartCoverデバイスを設置し、RDII、容量不足、およびオーバーフローの高リスク地域の3つをモデル化しています。<\/P>
まず、「Sewer Capacity Deficiency Metering Areas」と「Sewer RDII Metering Areas」という2つの新しい階層グループを作成しました。それぞれの階層グループ内に5つの階層（ランク1から5）を作成し、合計10の新しい階層を作りました。この階層構造の理由は（特にRDII調査地域では）、調査地域の最も下流のマンホールにSmartCoverを設置し、主幹線から分岐する異なる枝のマンホールに2～3台、その上流の小さな枝に1～3台設置し、必要に応じて繰り返すためです。調査地域内にある各下水道本管（および構造物）がどのサブネットワーク（すべての階層を通じて）に属しているかを把握する必要があります。<\/P>
階層グループ／階層を作成後にトポロジーを再有効化した最初の時点で、すべてのSewerLineフィーチャにトポロジーエラー（32: Error setting weight values . 32,[This weight cannot be null.]）が発生しました。このエラーについて調査し、ネットワーク属性と割り当てを確認しましたが、何も問題<\/STRONG>は見当たりませんでした。唯一疑わしかった属性は「Cathodic Protection Traceability」属性で、これはSewerDevice上の「cptraceability」フィールド（さまざまなサブタイプ経由）に割り当てられています。そのフィールドには私のデータで全てnull<\/EM>値が含まれていました。Esriソリューションから割り当てられたドメインは「CP_Traceability」ドメインでした。「Cathodic Protection Traceability」属性はnull許容設定なので問題になるとは思えませんでした。<\/P>Sewer Utility Network Foundation V1.2 のデータ辞書(https:\/\/solutions.arcgis.com\/water\/help\/sewer-utility-network-foundation\/DataDictionary\/DataDictionary\/<\/A>)を確認したところ、「cptraceability」フィールドのドメインが「Yes\/No」に変更されており、その値は0から2まで（0は不明、1はYes、2はNo）となっていました。直感で、「cptraceability」フィールドのドメイン割り当てを各SewerLineサブタイプで「Yes\/No」ドメインに変更しました。そしてCalculate Fieldを実行して全レコードの「cptraceability」値を0（ゼロ）に更新しました。データを再検証したところ、すべてのトポロジーエラーが解消されました。この問題がなぜ起きたかは完全には理解できませんでしたが、データが正常に動作していることに満足しました。<\/P>先週金曜日、「Sewer RDII Metering Areas」階層グループにさらに階層（ランク6から10）を追加しました。また、新しい「Sewer Risk Monitoring Metering Areas」階層グループを作成し、5つの階層（ランク1～5）を追加しました。<\/P>今朝、再びすべてのSewerLineフィーチャで以前と同じトポロジーエラー（32: Error setting weight values . 32,[This weight cannot be null.]）が表示されていることに気付きました。null値を含む他の属性はSewerLineフィールドにはありません。このエラーはどこから来ているのでしょうか？また、どうすれば修正できますか？<\/P>
先週金曜日、「Sewer RDII Metering Areas」階層グループにさらに階層（ランク6から10）を追加しました。また、新しい「Sewer Risk Monitoring Metering Areas」階層グループを作成し、5つの階層（ランク1～5）を追加しました。<\/P>
今朝、再びすべてのSewerLineフィーチャで以前と同じトポロジーエラー（32: Error setting weight values . 32,[This weight cannot be null.]）が表示されていることに気付きました。null値を含む他の属性はSewerLineフィールドにはありません。このエラーはどこから来ているのでしょうか？また、どうすれば修正できますか？<\/P>
@RobertKrisher the attribute rules for Cathodic Protection Traceability have been disabled since we implemented the Utility Network in 2023. I confirmed they are still disabled, so they are not altering the data in the cptraceability field.
@CarlVon_Stetten1 If you check the cp traceability field in your data again, has it become null again? There is an attribute rule that is responsible for calculating that value, and I suspect that when you're adding these tiers and their new fields, that the rule is being triggered when the subnetwork name is set to 'Unknown'.
The rule should return a 0, 1, or 2, but its possible with the modifications you've made to your model its returning a null value because something is exiting early.
@RobertKrisher I logged a case as you suggested (https://my.esri.com/#/support/cases/tech-cases?caseNumber=03804481 ).
To be clear, that particular network attribute is set to allow nulls, and the fields are also set to be nullable.
The reason I made the change to the domain assignment is that the "CP_Traceability" domain previously assigned has only two states (yes/no), but I don't know what the correct value would be for our data. I needed to be able to set the default and all of the existing records to Unknown, so I changed the domain assignment to what the more recent version of the Solution uses (the "Yes/No" domain).
Please log a case with support on this to investigate further.
Do you have copies of your database from before you made these changes? If you were just adding tier groups/tiers and setting subnetwork definitions it shouldn't cause these problems. What could have caused this problem is if you had made changes to your network attributes or network attribute assignment.
How the field is configured (to allow nulls) and how the network attribute is configured (to not allow nulls) are actually separate items. The interesting this is we don't allow you to assign a non-nullable network attribute to a nullable field, so that shouldn't have been possible. Changing the domain assignment shouldn't have affected anything, but calculating all the fields to be not null is what should have fixed the issue.
I had another hunch and thought maybe the same settings adjustments (cptraceability domain and default value) needed to be made to SewerDevice (even though the errors were about SewerLine). I made those adjustments and the topology errors disappeared.
I really do not understand what is going on here.
サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
