ModelBuilderでフィーチャレイヤーを使用することが重要なのはなぜですか？
回答:
モデルには、そのサイズと複雑さに応じて、多くのサブプロセス出力層がある場合があります。ハードディスクに書き込まれているファイルを削除するために、一部のツールではフィーチャレイヤーを使用できます（たとえば、[ フィーチャ選択の反復]または[属性で選択]）。フィーチャレイヤーは一時的なものであり、モデルの終了後は保持されません。
フィーチャクラスではなく、ModelBuilderでフィーチャレイヤーを参照する理由はいくつかあります。まず、違いを理解しておくと役に立ちます。
- 「機能クラス」は、全体として生データへの単なる参照として。FCがディスク上のシェープファイルであるこの1つの簡単な例。
- 「フィーチャレイヤー」は、データの抽象化への参照であり、データセット全体ではなく、生のデータセット内の1つまたは複数のフィーチャを操作できます。レイヤーは、データをArcMapに読み込んだ後で効果的に操作するものです。
その背景を踏まえ、生データと他のジオプロセシングツールの中間として「フィーチャレイヤーの作成」ツールを使用する理由をいくつか次に示します。
- ModelBuilderの多くのGPツールはレイヤーの使用を必要とし、FCを入力として受け入れません。これは、GPツールがデータを選択する必要がある場合に特に当てはまります。このシナリオでは、生データではなく、LAYERを操作する必要があります。例：ArcMap（または別のGISプログラム）を開いていなかった場合、生のシェープファイルからフィーチャをどのように選択しますか...できません。その選択を行うには、ArcMapでレイヤーを操作する必要があります。
モデルをArcCatalogから実行する場合、またはモデルをArcGISの外部で実行できるPythonスクリプトにエクスポートする場合は、生のソースデータを「レイヤー」に変換するために「フィーチャレイヤー」を使用する必要があります。これは、ArcMapセッションへの「データの追加」に似ています。
レイヤーを使用すると、ModelBuilderプロセスを進めながら、データを簡単にサブセット化できます。たとえば、属性「A」のすべてのデータを1つのメソッドで処理し、属性「B」のすべてのデータを別のメソッドで処理するとします。生データを1回参照してから、フィーチャレイヤーを使用してデータを2つの「ブランチ」に分割し、各セットを個別に処理しますが、単一のソースデータセットに影響を与える/更新することができます。
- 本当に一時的なデータ処理「ビン」である「in_memory」機能レイヤーを作成できます。これは、すべての操作の後にディスクに書き込むよりもはるかに高速にデータを処理できます。また、処理の完了後にクリーンアップする必要があるジャンクの量も制限されます。
一時レイヤーをモデルに組み込むと、処理時間も短縮されます。処理の観点からは、ディスクへの書き込みよりもメモリへの書き込みの方がはるかに効率的です。同様に、一時的なデータをin_memoryワークスペースに書き込むことができます。これにより、計算効率も向上します。
ArcGISの多くの操作では、入力として一時的なレイヤーが必要です。たとえば、[場所によるレイヤーの選択（データ管理）]は、別の選択機能と空間関係を共有するレイヤーの機能を選択できる非常に強力で便利なツールです。「HAVE_THEIR_CENTER_IN」や「BOUNDARY_TOUCHES」などの複雑な関係を指定できます。
編集：
好奇心から、フィーチャレイヤーとメモリ内ワークスペースを使用して処理の違いを詳しく説明するために、39,000ポイントが100mバッファーされる次の速度テストを検討してください。
import arcpy, time
from arcpy import env
# Set overwrite
arcpy.env.overwriteOutput = 1
# Parameters
input_features = r'C:\temp\39000points.shp'
output_features = r'C:\temp\temp.shp'
###########################
# Method 1 Buffer a feature class and write to disk
StartTime = time.clock()
arcpy.Buffer_analysis(input_features,output_features, "100 Feet")
EndTime = time.clock()
print "Method 1 finished in %s seconds" % (EndTime - StartTime)
time.sleep(5)
############################
# Method 2 Buffer a feature class and write in_memory
StartTime = time.clock()
arcpy.Buffer_analysis(input_features, "in_memory/temp", "100 Feet")
EndTime = time.clock()
print "Method 2 finished in %s seconds" % (EndTime - StartTime)
time.sleep(5)
############################
# Method 3 Make a feature layer, buffer then write to in_memory
StartTime = time.clock()
arcpy.MakeFeatureLayer_management(input_features, "out_layer")
arcpy.Buffer_analysis("out_layer", "in_memory/temp", "100 Feet")
EndTime = time.clock()
print "Method 3 finished in %s seconds" % (EndTime - StartTime)
time.sleep(5)
メソッド2と3は同等であり、メソッド1の約3倍高速であることがわかります。これは、フィーチャレイヤーを大規模なワークフローの中間ステップとして使用することの威力を示しています。
in_memoryワークスペースに書き込まれるデータはまだデータ（フィーチャクラスやテーブルなど）であり、それでも（潜在的に大量の）領域を占有します。一方、フィーチャレイヤーはデータのビューであり、データのサブセットを取得するためだけにデータを複製するのではなく、データのサブセットを選択して後続のプロセスで使用できます。フィーチャレイヤーが占めるスペースはほとんどありません。私はそれらを「メタデータ付きのポインタ」として考えるのが好きです。たとえば、それらはいくつかのデータを指し、クエリ/レンダリングする方法を説明します。
in-memoryワークスペースは基本的にメモリ内にあるファイルジオデータベースであると読みました。