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; } } }

LRS情報モデルの更新

Ayan Palit

LRSフィーチャーデータセットの要件

フィーチャーデータセットとは、共通の座標系を共有する関連するフィーチャクラスの集合です。フィーチャーデータセットは、トポロジー、ユーティリティネットワーク、パイプラインリファレンスなどのコントローラーデータセット（拡張データセットとも呼ばれることがあります）を作成する際に利用されます。拡張データセットに含めるフィーチャクラスは、まずフィーチャーデータセットに整理されます。

Pipeline Referencingでのサービスベースの編集をサポートするために、LRSデータモデル内の特定のフィーチャクラスはジオデータベース内のフィーチャーデータセットに存在する必要があります。フィーチャクラスとテーブルが事前にモデリングされている場合、以下のフィーチャクラスはフィーチャーデータセットに含まれていなければなりません：Centerline, Calibration Points, Redline, Networks, Events, and Intersections。

参照：LRS情報モデル

空間参照

フィーチャーデータセットを作成するときは、その空間参照を定義する必要があります。これには地理座標系または特定の投影法、座標単位、およびx、y、z、m値の許容誤差が含まれます。フィーチャーデータセット内のすべてのフィーチャクラスは共通の座標系を共有し、そのフィーチャのx,y座標は共通の空間範囲内にあるべきです。既存のフィーチャーデータセット内にフィーチャクラスを作成すると、その座標系はフィーチャーデータセットから継承されます。

メジャーとその精度は任意の線形リファレンス手法（LRM）の正確性にとって重要であるため、これらすべてのフィーチャクラスに対して空間参照、許容誤差、および解像度設定が一致している必要があります。これにより、ルート、イベント、および交差点のジオメトリとメジャーが線形リファレンスシステム（LRS）内で正確かつ整合性が保たれます。Centerline、Calibration Point、Redline、Network、Event、IntersectionのいずれかのフィーチャクラスがLRSに登録される前にモデリングされている場合は、許容誤差と解像度設定が一致していることを確認してください。

参照：許容誤差と解像度設定

実装上の考慮事項

Create LRS geoprocessing toolを使用してLRSおよび最小スキーマ項目を作成した場合、これら必須のフィーチャクラスは自動的にフィーチャーデータセットに配置されます。
LRSがArcMapまたはArcGIS Pro 2.5以前で作成された場合は、これらのフィーチャクラスをフィーチャーデータセットに移動し、ArcGIS Pro 2.6以降でLRSを編集するためにModify LRSジオプロセシングツールを実行する必要があります。このアップグレードプロセスではスキーマやAPR再構成への追加変更が必要になる場合があります。
Gas and Pipeline Enterprise Data Management ArcGISソリューションはLRS情報モデル要件に準拠しており、必須機能はUtilityNetwork フィーチャーデータセット内にあります。Gas and Pipeline Enterprise Data ManagementはArcGIS Pro 2.6、ArcGIS Enterprise 10.8.1、UPDM 2020、およびUtility Network Release 4に基づくネットワーク化および線形リファレンスパイプライン向け統合ソリューションです。

PODS 7.0もLRS情報モデル要件と互換性があり、必須機能はFeatures フィーチャーデータセット内にあります。
ArcGIS Pro 2.5以前のバージョンでのAPR実装では機能が単一データセット外に存在可能でした。ArcGIS Pro 2.6へアップグレード時にはGIS管理者へModify LRSジオプロセシングツール実行が促されます。上記データセット要件に従わない場合には以下のエラー130159が表示されます。

LRS交差点

ArcGIS Pro 2.6ではLRS交差点フィーチャクラスを構成し、交差点を生成・更新できるようになりました。以下はLRSルートと鉄道レイヤーとの交差例です。

LRS交差点クラスで必要なフィールドは以下の表に示されています。

< TD width = "25%" > Measure </ TD >< TD width = "20%" > Double </ TD >< TD width = "53%" > 交差点が位置する支配的ルート上のメジャー値。 </ TD ></ TR ></ TBODY ></ TABLE > 以下はLRSルートと鉄道レイヤーとの交差点属性テーブル例です。< H2 id = "toc-hId--603219239" >Redline</ H2 >ArcGIS Pro 2.8ではAPR情報モデルコアオブジェクトであるredlineフィーチャクラスはz対応でなければならず、m対応は禁止されています。

フィールド名	データ型	説明
Intersecting ID	Guid	交差IDフィールド名。
Intersection Name	テキスト (1000)	交差点名。
Route ID	テキスト (1000)	ルート固有ID。
Feature ID	テキスト (1000)	交差するフィーチャ固有ID。
Feature Class Name	テキスト (150)	交差点ポイントフィーチャクラス名。
From Date	日付	ネットワークが有効になった日付。
To Date	日付	ネットワークが廃止された日付。

タグ付けされた投稿をもっと見る

パイプラインとユーティリティ

Cristian_Galindo

Hello fellow,

Is there a way to move the feature classes involved in the LRS (programatically: Python) keeping the History and versioning information?

https://community.esri.com/t5/python-questions/move-feature-classes-reproduce-programmatically-move-drag-n-drop/m-p/1067788#M61354

Thanks!!!

Ayan Palit

Cristian_AndresGalindo_Londoño Moving Feature Classes (FC) from one Feature Datasets (FD) to another FD is a major schema change. Also, you may have to re-register or validate the FC's registered with the LRS. Due to this, I would recommend to reconcile, post and delete all versions prior to making these schema changes. Either Drag-n-Drop or Python script may be used but best to collapse the versions. Many clients also need to switch from traditional to branch versioning as part of the upgrade. In that case, the geodatabase will need to be unversioned, make changes as required for branch versioning and then register as branch version.

Cristian_Galindo

Thank @AyanPalit for your answer. I feel that is still in the air, How to handle the history of the FC.

With my attempts to solve this, I keep losing the history of the features classes involved in the move operation.

Any tipp?

Ayan Palit

Cristian_AndresGalindo_Londoño if you mean versioning history, best to reconcile and post all pending edits as suggested in prior response. If you have editor tracking enabled, the metadata captured as attributes will be preserved through the move.

Cristian_Galindo

@AyanPalit I was using the wrong term, I mean Archiving

Ayan Palit

Cristian_AndresGalindo_Londoño Is this a production environment with archiving and versioning enabled? Are you using traditional versioning? There are many considerations for upgrades to a production environment. which need careful planning and execution. I feel this goes beyond the Community forum and recommend additional review through other channels like Esri Tech Support.

Cristian_Galindo

Currently I am working in a development environment, but I must move those changes to production.

The geodatabases (Dev\Production) have archiving and versioning enable. As you state we are using traditional versioning.

Thanks for any additional tip.

Ayan Palit

Cristian_AndresGalindo_Londoño The recommended APR upgrade pattern includes migration to Branch Versioning. As noted previously, there are several/significant changes to the geodatabases:

Schema Change
Version Transaction Model
Archiving Model
LRS Registration

You can retain a backup of the legacy database. As part of the upgrade you are setting up a new/different versioning model that includes archiving. A careful review of branch versioning documentation, planning and execution is needed as part of the upgrade.

会話に参加する

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

クイックリンク

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