ポイントフィーチャに一意のIDを割り当てる

MassGISパーセルスタンダード（http://www.mass.gov/mgis/ParstndrdVer1_5_1.pdf）は、x座標とy座標の整数部分を連結して、フィーチャの一意のID（LOC_ID）を作成します。ポイントフィーチャクラスについても同じことを検討しています。私は一貫した方法論が好きですが、おそらく何かを見落としています。ポイントフィーチャに一意のIDを作成するための標準またはベストプラクティスはありますか？

別のテーブルに関連する外部キーなどにそのIDを使用すると、何らかの理由でポイントを移動しなければならない場合、データベース全体で大きな問題が発生します。おそらく、それがxy座標を記述しなくなったとしても、idを保持する必要があります。

ほとんどのデータは変更される可能性があるため、一意のキーは、データについて何も伝えていないものを持つのに最適です。

/ニクラス

Nicklasの回答と私のコメントから追加します。

私は最もよく使われる慣習と言って、最も推奨されるのは自動インクリメントIDを使用することです。たとえば、1から始めてそのまま続行します。論理はなく、単純です。

分散システムを使用している場合や、自動インクリメントの番号が気に入らない場合は、GUIDを使用できます。ほとんどのデータベースは、この種のIDの作成を処理します。ただし、ユーザーが手動で入力したり、検索したりするのが面倒なので、覚えておいてください。

他のオプションは、データのある種のハッシュを使用することですが、これはお勧めしません。つまり、これを行うためのアルゴリズムを作成する必要があるということです。一意性を常に保証できるとは限りません。また、検索のために入力するのが面倒になる傾向があります。

これらは私の意見にすぎませんが、個人的な経験から、信頼してください。IDでビジネスデータを使用することはありません。

追加質問：DBMS（SQL Server）またはGISソフトウェア（ArcGIS）で一意のIDを作成して維持するのが最善ですか？

DBMS内の一意性をチェックすることを強くお勧めします。これは、DBMSの多くの長所の1つです。また、固有の制約を認識していない可能性があるさまざまなGISソフトウェアを使用してデータにアクセスすることもできます。

私たちの識別方式は私が選択したのではなく、次のとおりです。資産のクラスである2、3、4文字コードと6桁の連続番号（使用できる桁数は何でも選択できます）。ストアドプロシージャはこれらのIDを作成し、同じSQL Serverデータベース内のいくつかの非ジオデータベーステーブルに依存します。

個別の連続する自動インクリメントIDを保持しています。13 ポイントのgeohashフィールド（ポイントフィーチャ用）も保持していますが、キーとして使用することはありません。機能が移動されるたびに、フィールドは（カスタムエディター拡張によって）自動入力されます。

GISデータをなんらかの資産管理システムで使用する場合、IDをジオデータベース内でグローバルに一意にする必要があります（おそらく、組織内のすべてのジオデータベース内で一意にする必要があります）。これにより、将来的にジオデータベースのリファクタリングが少し簡単になります。

私は過去に、CRC計算を使用して同様の値を作成しました。作成するのはそれほど難しくなく、ライブラリ/アルゴリズムはオンラインで入手できます。

利点は、ポイントよりも大きい機能を実行できることですが、連結は本当にポイント機能でなければなりません（本当に大量のキーが必要な場合を除く）。

とにかく、エンドユーザーがこのIDで検索することはまずないと思いますので、問題とは思いません。

そうは言っても、そのようにIDを割り当てることの明確な利点はあまりありません。変更検出にこの方法を使用する場合があります（2つのセットのジオメトリよりも2つのCRC値を比較する方がはるかに効率的であるため）それでも、なぜそれをプライマリIDとして使用するのですか？

「もちろん、GUIDはVBスクリプトを使用して生成できます。ただし、ESRIによるVBスクリプトの段階的なディエンファシスを考慮して、世界の9番目の不思議なPythonを使用して、ArcMapでGUID生成を実行します。Pythonをまだ使用していない場合はPythonはGISハッカーを熱狂させる神からの贈り物です。私のアドバイス：学ぶ！生きる！愛する！」

http://eaglemap.com/blog/bid/45555/How-to-Generate-GUIDs-in-ArcMap

ESRIのArc Hydro Toolsには、バックグラウンドで実行される一意のIDマネージャーもインストールするツールバーが付属しています。ツールバーを使用すると、フィーチャクラスごとまたはジオデータベースごとに一意のIDを割り当てることができます。デフォルトのIDマネージャーは、Arc Hydroデータモデルの一部であるHydroIDなどと呼ばれる一意のID属性のみを処理します。ただし、他の属性を処理するように設定することもできます。ツールには多くのドキュメントが付属しているため、IDマネージャーを必要に応じて構成しても問題はありません。

一意のIDは、私の知る限り、常に整数です。一意のIDを割り当てた後、マネージャーは、構成に適合する新しく作成された機能ごとに新しい一意のIDを割り当てます。

一意のIDマネージャーは、パーソナルジオデータベースのような自動インクリメント番号を（AFAIK）がサポートしていないデータベースバックエンドに役立ちます。