GDALでFileGDBのパフォーマンスが遅い

GDAL 1.9.2のコンパイルを使用して、ESRIファイルジオデータベースに多くのASPRS LASポイントファイルを書き込もうとしています。GDAL / OGRのFileGDBドライバーは、大きなファイルを書き込むときに信じられないほど遅く、800万ポイントのレコードを書き込むのに45分もかかります。SATA3ドライブでGDALを使用するFileGDBの書き込み速度は、毎秒200キロバイト程度であり、テラバイトのデータを変換しようとすると許容できないほど低速になります。

FileGDBのドキュメントで、FGDB_BULK_LOADマクロを定義すると大規模なデータセットのパフォーマンスが向上することに気付きましたが、FGDB_LIBの直後に「FGDB_BULK_LOAD = YES」というテキストを含む行を「nmake.opt」ファイルに書き込んだとき、パフォーマンスに変化はありませんでした。ライン。

確かに、FileGDBは何十億ものポイントデータレコードを格納するための理想的な方法ではありませんが、それは別の時代には不便です。FGDB_BULK_LOAD機能を正しく使用しましたか？これは、GDALビルドではなく、私のソースコードにあるはずですか？

ありがとう。

更新：適切な使用法：（チャットで回答）

FGDB_BULK_LOAD設定が正しくGDAL / OGR・プロセスの環境変数として格納されます。これは、Ragiが示すように、ogr exe呼び出し中にコマンドラインで設定されます。GDAL機能を使用すると、プログラムで設定することができ、全体のプロセスのために

 CPLSetConfigOption("FGDB_BULK_LOAD", "YES");

または現在のスレッドだけを使用して

 CPLSetThreadLocalConfigOption("FGDB_BULK_LOAD", "YES");

FGDB_BULK_LOADを呼び出す前に設定する必要がありますFGdbDataSource::CreateLayer()。OGRCleanupAll()この変数の設定を解除するかどうかは明確ではありませんでしたが、念のため複数回呼び出しても安全です。

このオプションを使用すると、数百万から数千万のポイントを書き込む場合のパフォーマンスが約5.5倍速くなりました。

FGDB_BULK_LOADはコンパイル設定ではなく、コマンドラインツールの構成オプションです（プログラムで実行することもできます）。

ogr2ogr --config FGDB_BULK_LOAD YES -f "FileGDB" MyFileGDB.gdb myKML.kml

filegdbを作成し、それにKMLベクトルデータをロードします。それでもパフォーマンスが悪い場合はお知らせください。ところで、あなたはどんなプラットフォームを使っていますか？

更新：

チャットとIRCで議論されたことを要約すると、

プログラムによるアクセスの場合：

 OGRDataSource* datasource = driver->Open("c:/myfilegdb.gdb", TRUE); 
 char* options[] = { "FGDB_BULK_LOAD=YES" , NULL }; 
 OGRLayer newlayer = datasource->CreateLayer("tiny", NULL, wkbPoint25D, options);

同等である必要があります。