Langsame FileGDB-Leistung in GDAL

Ich versuche, mit meiner Kompilierung von GDAL 1.9.2 viele ASPRS-LAS-Punktdateien in eine ESRI-Datei-Geodatabase zu schreiben. Der FileGDB-Treiber für GDAL / OGR scheint beim Schreiben großer Dateien unglaublich langsam zu sein. Das Schreiben von nur 8 Millionen Punktdatensätzen dauert bis zu 45 Minuten. Die Schreibgeschwindigkeiten von FileGDB mit GDAL auf einem SATA3-Laufwerk liegen in der Größenordnung von 200 Kilobyte pro Sekunde, was unannehmbar langsam ist, wenn ich versuche, Terrabyte an Daten zu konvertieren.

In der FileGDB-Dokumentation habe ich festgestellt, dass das Definieren des Makros FGDB_BULK_LOAD die Leistung für große Datenmengen verbessern sollte. Ich habe jedoch keine Änderung der Leistung festgestellt, als ich unmittelbar nach der FGDB_LIB eine Zeile in die Datei "nmake.opt" mit dem Text "FGDB_BULK_LOAD = YES" geschrieben habe Linie.

Zugegeben, eine FileGDB ist nicht der ideale Weg, um Milliarden von Punktdatensätzen zu speichern, aber das ist ein Problem für ein anderes Mal. Habe ich die Funktion FGDB_BULK_LOAD richtig verwendet? Soll das in meinem Quellcode sein, nicht im GDAL-Build?

Vielen Dank.

UPDATE: Richtige Verwendung: (Im Chat beantwortet)

Die FGDB_BULK_LOADEinstellung wird ordnungsgemäß als Umgebungsvariable für den GDAL / OGR-Prozess gespeichert. Dies wird in der Befehlszeile während des von Ragi gezeigten ogr exe-Aufrufs eingestellt. Mit den GDAL-Funktionen kann es programmgesteuert für den gesamten Prozess mit eingestellt werden

 CPLSetConfigOption("FGDB_BULK_LOAD", "YES");

oder nur für den aktuellen Thread mit

 CPLSetThreadLocalConfigOption("FGDB_BULK_LOAD", "YES");

FGDB_BULK_LOADmuss vor dem Anruf eingestellt werden FGdbDataSource::CreateLayer(). Es war unklar, ob OGRCleanupAll()diese Variable deaktiviert wurde, aber es ist sicher, mehrmals aufzurufen, um sicherzugehen.

Durch die Verwendung dieser Option wurde die Leistung beim Schreiben von Millionen bis zig Millionen Punkten um das 5,5-fache gesteigert.

— Phlucious
quelle

FGDB_BULK_LOAD ist keine Kompilierungseinstellung, sondern eine Konfigurationsoption für die Befehlszeilentools (kann auch programmgesteuert ausgeführt werden).

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

Würde eine filegdb erstellen und die KML-Vektordaten in diese laden. Lassen Sie mich wissen, ob Ihre Leistung immer noch schlecht ist. Auf welcher Plattform bist du übrigens?

Aktualisieren:

Um zusammenzufassen, was im Chat und im IRC besprochen wurde:

Für programmgesteuerten Zugriff:

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

sollte das Äquivalent sein.

— Ragi Yaser Burhum
quelle

Danke für Ihre Antwort. Ich arbeite unter Windows 7x64, codiere in C ++ auf Qt Creator und kompiliere mit MSVC2010. Mir war nicht klar, dass dies eine Befehlszeilenoption war. Ist es möglich, diese Leistungsverbesserung beim Codieren aus der Bibliothek zu nutzen?

— Phlucious

Allgemeiner GDAL / OGR-Kritikpunkt: Die meisten Konfigurations- und Verwendungsanweisungen auf den Treiberseiten sind ausschließlich auf die Verwendung in der Befehlszeile ausgerichtet, während mein Anwendungsfall die Integration der GDAL / OGR-Bibliothek in meinen Code erfordert. Gibt es eine auf Entwickler ausgerichtete Dokumentressource, von der ich nichts weiß?

— Phlucious

@Phlucious Hier gibt es den Abschnitt Ressourcen: gdal.org/ogr , der reichlich Entwicklerdokumentation enthält. Am Ende ist die beste Dokumentation der Quellcode selbst. Der gesamte Quellcode für den FileGDB-Treiber besteht nur aus 7 Dateien und ist hier verfügbar: github.com/OSGeo/gdal/tree/trunk/gdal/ogr/ogrsf_frmts/filegdb . Wenn Sie sehen möchten, wie die Flagge verwendet wird, können Sie hier nachsehen: github.com/OSGeo/gdal/blob/trunk/gdal/ogr/ogrsf_frmts/filegdb/…

— Ragi Yaser Burhum

Die Art und Weise, wie die Einstellung weitergegeben wird, besteht einfach aus einer Reihe von Zeichenfolgen. Sie können dies herausfinden, indem Sie hier

— nachsehen.

Was Sie sagen, macht Sinn. In meiner Anwendung mit Feature-Classes in der Größenordnung von Millionen bis zehn Millionen Punkten konnte ich eine Leistungssteigerung von 5,5 bis 6,0 feststellen. Ziemlich beeindruckend! Ich habe auch gelernt, dass mehrere Threads in dieselbe FileGDB schreiben können, solange sie in verschiedene Elemente schreiben, was die Leistung noch weiter steigert.

— Phlucious