タグ付けされた質問 「enterprise-geodatabase」

このタグは、ArcGIS for Serverのエンタープライズジオデータベース(以前のバージョンのArcSDE)コンポーネントに関する質問に使用します。

2
SQL Serverジオメトリライン(ArcSDE)で重複する頂点を見つける
無効なジオメトリを持つZMポリラインフィーチャクラスにラインがあります。私の疑いは、行がどこかで2倍に戻っていることです。SQLServerが気に入らないことがわかりました。ジオメトリを妨害している疑わしい不良ポイントを特定するのに役立つ簡単なSQLメソッドまたはクエリを知っている人はいますか?文字列表現は次のようになります。 1835815.86 12887142.42 0 0, 1835816.72 12887142.68 170 170, 1835817.53 12887142.76 349.99 350, 1835817.52 12887142.76 559.99 560, 1835817.78 12887142.76 659.99 660, .... また、正規表現と先読みや後ろ向きを使用して重複する数字を見つけることができるかどうか疑問に思っていますか?

3
ArcMapでアンダースコア文字をクエリしますか?
OracleベースのArcSDEフィーチャクラスに対する標準のLIKEクエリの場合、アンダースコア文字は、文字列と一緒に使用すると、1文字のワイルドカードを表します。 私は定義クエリを課して、4桁で始まり、その後にアンダースコア文字が続くテキスト文字列を検索しようとしています。 誰かがクエリでアンダースコア文字自体をどのように指定するのか、またはエスケープ文字が何であるかを知っていますか? MDHaldの回答はファイルジオデータベースで機能しますが、私のケースはOracleに固有です。この場合、ArcSDEとファイルジオデータベースクエリは同じように機能すると誤って想定されていました。

1
空間的な「多対1」結合の作成
私は「多対1」の結合と呼ばれるものを作成しようとしています。それが正しい言葉かどうかはわかりません。パーセルのアカウント番号(R0003285)ごとにモバイルホーム(つまり-M1007970)の一意のアカウント番号を持つテーブルがあります。(パーセルごとに多くのモバイルホーム-多対1。)このテーブルをパーセルジオメトリに結合する必要があります-それでも、パーセルごとに1つのポリゴンしかありません。 したがって、たとえば、テーブルには3つの行があり、1つの行にモバイルホームアカウント番号M1007370、別の行にM1007371、および別の行にM1059370がありますが、すべて同じパーセル番号R0032585です。パーセルジオメトリには、R0032585と同じフィールドしかありません。 入会すると、12,088のモバイルホームレコードと44,103の小包があります。「すべてのレコードを保持する」場合、7,947のモバイルホームアカウント番号(元の12,088)だけの44,103レコードがあります。「一致するレコードのみを保持」に基づいて参加すると、合計で7,947件のレコードしか得られません。 過去に成功し、モデルを作成しました。このモデルでは、モバイルホームのテーブルを使用して、パーセルアカウント番号に基づいてパーセルレイヤー(.lyr-モデルで結合できる/結合できる唯一の方法)に結合します。一致するレコードのみを保持するフィーチャをファイルジオデータベースにコピーします。次に、ファイルジオデータベースからSDEシステムに追加します。何も変わっていないので、これは私が理解できない理由で現在動作を停止しました。 おそらく、誰かが私がやろうとしていることよりも上手に伝えることができ、それが多対1関係以外のものと呼ばれる場合は(1対多だとは思わない...)。

1
アーカイブテーブルを含むSDEジオデータベースを複製できますか?
一方向のレプリケーションを使用して別の場所にレプリケートするデータベースを1つの場所に持っています。テストでは、アーカイブテーブルを複製できませんでした。これらの履歴バージョンを両方の場所に保持する必要があるため、残念です。 DEFAULTデータベース全体(アーカイブテーブルを含む)を単純に複製することは可能ですか? そうでない場合、これを回避する方法はありますか?

1
ArcObjectsで大規模な編集セッションを調整すると、サーバーメモリが不足する
Out of Server Memory大規模な編集セッションを調整しようとすると、ArcSDE 10.0で定期的にエラーが発生するユーザーがいます。 VMware ESXインスタンス: Windows Server 2008 R2データセンター サービスパック1 Intel Xeon E5-2660 @ 2.20GHz 8 GBのRAM メモリ使用量を追跡するためにパフォーマンスモニターをセットアップしましたが、これがバージョン付き編集で他の誰かが経験した問題であるかどうか知りたいですか? 私たちのRDBMSはOracleであり、ESRIがこのページを見つけました。 http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//002n00000026000000 ただし、これは、ArcSDEとOracleが同じマシン上にあると想定しているようです(私たちにとってはそうではありません)。編集ユーザーに関連付けられている「無制限」のテーブルスペースを削除する必要がありますか? また、Oracleクライアントを使用してデータベースに直接接続します。これは、おそらく間違ったサーバー(ArcSDE)を見ていて、DBAと話している必要があることを意味しますか?ArcObjectsエラーはArcSDEの問題を意味すると思いますが、おそらく誰かがこれを修正できますか? 解決策は、編集を担当していたデスクトップで64ビットのバックグラウンドGPを有効にすることでした。大規模な編集セッションは、Oracleジオデータベースに問題を引き起こすようです。おそらくRDBMSレベルで解決できた可能性がありますが、DBAはその時点でトラブルシューティングを行うことができませんでした。

1
ArcPyを使用して履歴バージョンに変更しますか?
Pythonとarcpy.ChangeVersion_managementを使用してSDEフィーチャクラスの履歴バージョンに変更しようとすると問題が発生します。 ArcMapを使用して、手動でバージョンを特定の日時に変更できます。ModelBuilderを使用してプロセスを完全に自動化することもできます。 ModelBuilderモデルをPythonスクリプトにエクスポートすると、スクリプトはエラーなしで実行されますが、選択されたバージョンは、日付パラメーターとして選択された日付ではなく、今日の日付の履歴バージョンです。 ArcmapとPythonウィンドウを使用して(ジオプロセシング-> Python)、Pythonコードをエラーなしで実行することもでき、結果は同じです。履歴レイヤーは、日付パラメーターとして選択された日付ではなく、現在の日付で選択されます。 これが私が実行しているPython構文です: arcpy.ChangeVersion_management("Parcels", "HISTORICAL", "", "7/1/2013 4:30:00 PM") 私も同じ結果が得られます: historyDate = datetime.datetime(2011, 7, 1) arcpy.ChangeVersion_management("Parcels", "HISTORICAL", "", historyDate) 一方、以下はRuntimeErrorをスローします。 historyDate = datetime.date(2011, 7, 1) arcpy.ChangeVersion_management("Parcel", "HISTORICAL", "", historyDate) これは既知のバグですか、それとも間違った方法で進んでいますか?

1
「編集をベースに移動」オプションを使用してデータがバージョン管理されているかどうかを確認する方法はありますか?
「編集をベースに移動」オプションを使用してデータがバージョン管理されているかどうかを確認する方法はありますか? できれば、ArcGIS自体またはPythonを使用しますが、どの方法でも機能します。 編集 データのバージョン管理時にこのボックスがオンになっていたかどうかを確認する方法はありますか?

4
ArcPyを使用してArcSDEジオデータベースをファイルジオデータベースにコピーしますか?
SDEデータベースの正確なコピー(ドメイン、フィーチャデータセット、フィーチャクラスなど)をファイルジオデータベースに作成したいと考えています。 私は以下を含むいくつかの可能性を試しました: コピー(データ管理)プロセスの使用 新しいGDBを作成し、SDEから各フィーチャデータセットを手動でコピーする SDEからxmlワークスペースドキュメントをエクスポートし、GDBにインポートする このCopy_managementプロセスは、SDEをGDBにコピーする場合には機能しないようです。これは、入力と出力のデータ型が一致している必要があるためです。 各フィーチャデータセットを新しいGDBにインポートするプロセスは、各フィーチャデータセットを反復処理することで、おそらくCopy_managementを使用して自動化できますが、いずれかのプロセスでエラーが発生した場合、不完全なコピーの問題が発生する可能性があります。 XMLワークスペースのエクスポートとインポートは機能するようですが、このプロセスを大規模なジオデータベースで使用すると、非常に大きなファイルが作成されます。 自動化できる方法で、SDEのコンテンツとスキーマをGDBにコピーする方法として、前述の方法よりも簡単な方法はありますか? そうでない場合、上記の可能性をこのプロセスで使用すべきでない理由はありますか?

1
QGISおよびArcGISでPostgreSQLを使用しますか?
QGISおよびArcGISでPostgreSQLを使用することは可能ですか?つまり、異なるクライアント用の1つのデータベース。 2つの異なるソフトウェアからDBMSを使用するのに心配や問題はありますか? PostGISとArcSDEが必要であり、QGISからPostgreSQLのPostGIS 1.5でラスターデータを操作または保存できないことはわかっています。 あなたは何を勧めますか、何を避けますか?

2
バージョン対応のジオデータベースで、デルタテーブルと状態ツリーはクエリのパフォーマンスにどのような影響を与えますか?
バージョン化されたarcsdeジオデータベース(oracle 10gのarcgis 9.3.1)には、約100のフィーチャクラスと非空間テーブル、ジオメトリックネットワーク、および多くのリレーションシップクラスを含むかなり複雑なデータモデルがあります。 データは、sdeバージョン管理を利用して5人または6人のarcmapユーザーによって毎日編集されます。さらに、バージョンは、ジオデータベースで編集を実行するために他のビジネスシステムと連動する自動サービスによって作成されます。クエリのパフォーマンスは1日の間に著しく低下するため、完全な圧縮を実現するために毎晩スクリプトを実装しました。比較的多数の編集が実行される場合、システムは完全に圧縮されるまで使用できなくなる可能性があります。 設定されたoracleは、これらの揮発性デルタテーブルに直面した場合、まともな実行計画を立てることができないことが示唆されています。これは合理的な説明ですか?それを解決するためにどのようなアプローチを取るべきですか? コメントに応じて更新 1日の終わりまでに、状態ツリーは非常に線形であり、分岐はほとんどありません。 毎晩圧縮します(すべてのバージョンを削除して完全な圧縮を取得します)。 ビジネステーブルは定期的に分析されます。 デルタテーブルは分析されません。それらはロックされています(分析しようとすると、エラー「ORA-20005オブジェクト統計がロックされています」が返されます)。sdeスキーマの揮発性テーブルもありません-STATES、STATE_LINEAGES。

1
ArcSDEでのSQL Serverの関係
SQL Server 2008 R2 Standard EditionでArcSDE 10を実行しています。SDEとSQL Serverは初めてですが、SQL Serverにはテーブル間の関係を作成し、特定の参照整合性ルールを維持する機能があることを理解しています。 ArcGISには同様に機能するリレーションシップクラスがありますが、リレーションシップクラスにはSQLリレーションシップのすべての機能があり、ArcSDEデータベースでSQLリレーションシップが発生するわけではありません。 ArcGISでArcSDEデータベースのリレーションシップクラスを作成し、SQL Serverの同じテーブルのリレーションシップを作成することはできますか?そうすることで、ArcGISとSQL Server Management Studioのどちらでデータを操作していても、これらの関係を利用できます。2つのタイプの関係が互いに競合したり、パフォーマンスを妨げたりしませんか?

1
ESRIでの大規模なジオコーディングと処理
わかりましたので、ESRIの世界で使用しているデータセットの大きさについて、このような非公式のクエリ/調査を行っていると思います... 私は、州全体のデータセットを構築して維持しています。小包レベルですが、システムの小包ごとに複数の郵送先住所があります。多くの場所で、ストリートネットワークまたはUSPS AMS / AISデータから計算された理論上の住所を使用しています。したがって、私のアドレス一覧はおよそ1350万のアドレスであり、毎月または四半期ごとに増加しています。 連続データセットでこれほど大きいアドレス/適切に検索された情報のライブシステムを維持している人はいますか?他の人がこのような大規模なデータセットをどのように処理しているかについて、協力したり話したりしたいと思います。交差や空間結合などのタスクを実行しようとすると、ESRIソフトウェアが爆破しているように見える問題が発生しています。ESRIは、これらの種類の問題は表示されないと述べていますが、9.3.1に戻って以来これらの問題があり、複数のマシンで再作成できるため、私はこれを最初または唯一の人にすることはできません。現在の私のプラットフォームは、デスクトップ上のESRI ArcGIS 10であり、GEOMETRY空間オブジェクトを使用してSQL2008バックエンド上のArcSDE 9.3.1-sp1と通信しています。だから私は本当にエキゾチックなことは何もしていません。しかし、それでも私には、いくつかの地域ではおそらく限界を押し上げているようです。[さらに]私が知りたいのは、これらのデータセットを処理するためのプロセスを最適化するために他の人が何をしているのかです。今後は毎月100万レコードのアップワードを追加する予定です。他のプロセスの実行を開始し、さらに分析するためにデータをリンクすると、複雑な結合の処理を開始するので、ジオコーディングなどは問題になりません。さて、Only_FIDを使用してIntersects / Overlays / Identitiesからデータを出力し、薄い中間テーブルを結合することもできます。しかし、そのテーブルの作成を分割して征服しようとすると、ソースデータを作業領域に分割する必要があるという問題が発生し始めますが、マージできない繰り返しIDSがあります。そのため、全体を簡単に作成することができない小さなデータブロックが残ります。 データを郡ごとの規模に分解し、空間ビューを使用してデータを結合するオプションなどについて考えます。他のユーザーが同じような問題をこのような大規模で小規模に見ている場合に興味があります。足跡。

1
Esriジオデータベースの全文検索を実行しますか?
Esriジオデータベースでフィーチャのコンテンツ、属性列の値を検索するにはどうすればよいですか?(file-gdbの設定ですが、SDEも役に立ちます。) XMLワークスペースのエクスポートを使用してgdb全体をダンプし、結果を文字列(yuk!)で検索するか、PythonバージョンのSelect by Attributesですべてのテーブルをループするワークフローを想定できます。これらの両方があろうが働く、彼らは魅力的なされていません。 目標は、次のような質問に効率的に回答できるようにすることです。これらの50のフィーチャクラスのうち、「ケノ」と関係があるのはどれですか。


2
非常に遅いArcSDE 10.1データ表示の回避策はありますか
ArcgisエンジンアプリケーションからのデータとArcSDEデータベースの表示が非常に遅いので、SDEデータベースはローカルホストにあるため、ネットワークの問題はありません。しかし、私はまだこの問題を解決する方法も理由もわかりません。 2 CPUのXeon 3.4 GHzと2 GbのRAMを搭載した64ビットマシンで作業しています。 データベースには20のフィーチャクラスが含まれていますが、一部のフィーチャクラスではフィーチャの最大数が100 000を超えていません。データの表示を待つ場合、10分間待つ必要があります。 データベースのインデックスを圧縮して再構築しようとしましたが、改善はまったくありません。 ArcMapからデータを表示しようとしましたが、同じ問題が見つかりました。 パフォーマンスモニターを使用して、CPUとネットワーク側のいくつかのボトルネックを指摘しました。 SDEINTERCEPTの詳細: @travisアドバイスを試したので、Arcmapを使用してsdeでmxd参照データを開き、この部分に7分かかると述べました。 [W 10:34:37.710] Command: QueryWithInfo [R 10:34:37.710] Long: 1 [R 10:34:37.710] Query Info: Num Columns: 1 Columns: "shape" SQL_Construct: [1] Tables: "gebase.sde.point" WhereClause: "type_point_id<3" Query Type: 4 Num Hints: 0 Num Parameter markers: 0 Logfile: <null> [W 10:34:37.718] …

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.