ArcPyを使用してArcGIS DesktopでポイントごとにArcSDEポリゴンを選択しますか？

15

私は何かが足りないに違いないと考え続けていますが、ArcPyを介してポイント（X、Y）の位置にあるレイヤーからフィーチャ（特にポリゴン）を選択するツールはArcGIS 10にはないようです。このようなツールのパラメーターは、レイヤー名とXYロケーションのみです。

現時点では、ポイントを含むポイントフィーチャクラスを作成し、その上でSelectLayerByLocationを実行することでこれを回避します。ただし、ポリゴンフィーチャクラスがOracleにあり（ArcSDE 9.x経由でアクセス）、350万個のポリゴンが含まれている場合、選択を行うのにかかる時間は、2、3秒（より少ないコードで）より適切な。フィーチャクラスには空間インデックスがあり、arcpy.env.extent（SelectLayerByLocationが無視するように見える）を使用してアクセスする地理的領域を制限しようとしましたが、パフォーマンスは非常に低いままです。

ArcGIS Desktop 10とArcPyを使用してこれを行う簡単な方法はありますか？

— PolyGeo
ソース

forums.arcgis.com/threads/…でこれに対する解決策があります。この情報は本日中に編集します-Jason ScheirerとChris Snyder

— PolyGeoに感謝します

2

これへのメモとして、ツールのリファレンスページの下部にあるツールによって尊重される環境を見つけることができます。SelectByLocationは、現在のワークスペースと出力座標系のみを尊重します。help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//...

— blord・カスティーヨ

9

これに対する別のアプローチは、空間結合ツールを使用することです。上記のようにポイントを入力フィーチャレイヤーとして使用し、ポリゴンレイヤーをアイデンティティフィーチャとして使用します。
SelectLayerByLocationとは異なり、SpatialJoin はエクステント環境を尊重します。

targetlayer = layername
joinlayer=arcpy.PointGeometry(arcpy.Point(x, y))
fieldmappings = arcpy.FieldMappings()
fieldmappings.addTable(targetlayer)
arcpy.SpatialJoin_analysis(targetlayer, joinlayer, outputlayer, "JOIN_ONE_TO_MANY", "KEEP_COMMON", fieldmappings)

JOIN_ONE_TO_MANYは直感に反するように見えるかもしれませんが、結合機能は1つしかないため、このオプションの主な機能は、集約とマージルールをオフにすることです。KEEP_COMMONは、出力がポイントと交差するポリゴンのみに制限されるようにします。Fieldmappingsは、出力属性をポリゴンレイヤーの形状と属性のみに制限します。デフォルトにはポイントレイヤーの属性も含まれます。

残りのデフォルトは正常に機能するため、残りの引数は省略できます。

— ブロード・カスティージョ
ソース

私が試したことがなかったいくつかのテクニックを含んだこのコードに感謝します。以前にSpatialJoinを試してみました（ジオプロセシング環境を尊重できるようにするため）が、そのテストと今のテクニックのテストでは、まだ10〜12秒であったのに対して4〜5分の応答時間が残っていました。クリス・スナイダーが私を導きました。

— PolyGeo

クリス・スナイダーのテクニックもSpatialJoinで試しましたか？バッファテクニックが非常に高速である主な理由は、ポリゴンクラスのメモリ内コピーを使用するためだと思います。場所による選択は、空間結合よりも速くなるはずですが、よくわかりません。

— blord-castillo

in_memoryビットを使用しないことになりました。それはすでに非常に高速化されていたので、私はそれを予備にした。重要なのは、X、Yをチェックしてローカルファイルジオデータベースにすばやくコピーする必要がある1つまたはいくつかのポリゴン（350万から）を取得する範囲を設定することだったと思います。したがって、SpatialJoinの前にその部分を実行すると、同じ/同様のパフォーマンスの改善につながると思います。

— PolyGeo

1

何かに気付いた...

これを使用してジオプロセシングサービスを実装する場合は、代わりにポリゴンレイヤーを使用してフィーチャサービスを実装し、フィーチャサービスでクエリ操作を使用することもできます。

あなたはできる機能サービス照会操作とシンプルなXYの場所を使用するだけでなく、出力は形状を含む属性を制御します。

ポリゴンフィーチャクラスを公開できる量に制限がある場合がありますが、既にジオプロセシングサービスにアクセスできるようにしている場合は、フィーチャサービスも構築できるはずです。

— ブロード・カスティージョ
ソース

これは他の要件を満たすのに便利な考え方ですが、この場合、クライアントアプリケーションは非常に単純であり、私の制御が及ばないため、ジオプロセシングサービスのみを提供できます。

— PolyGeo

ジオプロセシングサービス以外の使用には制限があるかもしれないと考えました:)皮肉なことに、フィーチャサービスは実装と保守のためのはるかに単純なルートだと思います。これは、必要な機能が利用できない理由を説明する場合もあります。すべてのアプリケーションレベルで既に実行できます。次のバージョンのツールとして実装するために、ESRIにリクエストを送信してください。

— blord-castillo

1

この回答は、古いArcGISディスカッションフォーラムから寄せられました。

さらに簡潔なコードを提供してくれたJason Scheirerに感謝します。

SelectLayerByLocation(in_layer=arcpy.PointGeometry(arcpy.Point(x, y)), select_features="mylayer")

特にChris Snyderにパフォーマンスのヒントを提供しました。

より迅速な回避策は、ポイントを少しバッファリングしてから、そのバッファエクステントを分析エクステントとして使用してSDEデータのin_memoryコピー（CopyFeaturesツール）を作成し、小さくてローカルなin_memoryデータセットでSelectByLocationを実行することです。そうすることで、SelectByLocationツールが通常は実行しない分析範囲環境を尊重するようになります。ところで：解析範囲と重複するフィーチャは、CopyFeaturesツールを使用してコピーされます。SelectByLocationツールとカーソルメソッドが分析範囲を尊重することを確信しています...

— PolyGeo
ソース