Wie Sie durch Ausprobieren herausgefunden haben, mussten Sie nur wenige Probleme beheben, von denen das letzte mit dem Argument -nlt GEOMETRY
* von ogr2ogr behoben wurde .
* Beachten Sie die Empfehlung in @ LeeHachadoorians Kommentar, -nlt PROMOTE_TO_MULTI
die als Standardlösung verwendet werden soll und nicht nlt GEOMETRY
, da erstere zusätzlich zu den zusätzlichen Vorteilen die Best Practice fördert.
Benutzerberechtigungen und Fehlermeldungen
Erstens konnte ogr2ogr Ihr Shapefile nicht öffnen, und Sie stellten fest, dass Berechtigungsprobleme tatsächlich den Betriebssystembenutzer betrafen, der auf Ihr Shapefile zugreift. Aber es gibt hier eine wichtige Lektion für andere, insbesondere war die Fehlermeldung von ogr2ogr in diesem Punkt irreführend! In der Tat dachte einer der ersten Kommentatoren, Ihr Shapefile sei ungültig, und zugegebenermaßen war meine erste Vermutung, dass der Pfad / Dateiname wahrscheinlich einen Fehler / Tippfehler enthält oder dass der Dateipfad ein unkonventionelles Zeichen enthält - wie z space - das hat die Fähigkeit von ogr2ogr gebrochen, auf das Shapefile zu zeigen. Wie Sie festgestellt haben, handelte es sich eigentlich nur um ein Problem mit den Benutzerberechtigungen. Da die Fehlermeldung einen roten Hering erzeugt, ist dies eine Möglichkeit, die andere im Hinterkopf behalten müssen. :)
SQL-Benutzerrechte und Mystery-Fehler
Ich wäre eine Weile von Ihrem zweiten Fehler überrascht gewesen, aber als Sie Ihren SQL-Benutzer mit einem anderen Importdienstprogramm (shp2pgsql) getestet haben, das klug war, haben Sie eine genauere Fehlermeldung erhalten und Ihrem SQL-Benutzer die erforderlichen Berechtigungen für die spatial_ref_sys
Tabelle erteilt . Daher sollte jemand, der Schwierigkeiten hat, seine ogr2ogr-Importanweisung zum Funktionieren zu bringen, sicherstellen, dass sein SQL-Benutzer über ausreichende Berechtigungen sowohl für die Datenbank selbst als auch für die Tabelle 'spatial_ref_sys' verfügt.
Gemischte Geometrietypen und Best Practices
Die letzte Hürde, auf die Sie gestoßen sind, hängt anscheinend mit der Tatsache zusammen, dass Shapefiles die Koexistenz von ein- und mehrteiligen Geometrien in demselben Datensatz / derselben Datei ermöglichen. Es wird als schlechte Praxis angesehen, Geometrietypen in derselben Tabelle zu mischen, auch für einzelne / mehrteilige Elemente desselben Feature-Typs. Standardmäßig versuchen die Open Source-Player in Ihrer Toolchain, Sie vor dem Mischen von Geometrietypen zu schützen. Glücklicherweise bieten sie Ihnen einige Optionen. Ursprünglich empfahl ich, das Argument -nlt GEOMETRY
* in Ihrer Anweisung ogr2ogr zu setzen, damit Sie Ihr Polygon-Dataset trotz der lockereren Konvention von ESRI importieren können. Beachten Sie jedoch, dass Sie wahrscheinlich sowohl einteilige als auch mehrteilige Geometrien in Ihrer Tabelle haben. Dies kann später zu weiteren Kopfschmerzen führen!
Es ist erwähnenswert, dass Ogr2ogr eine andere -nlt
Option hat, die Sie in Betracht ziehen sollten, nämlich PROMOTE_TO_MULTI
. Um die Dokumentation zu zitieren ..
Ab GDAL 1.10 kann PROMOTE_TO_MULTI verwendet werden, um Layer, die Polygone oder Multipolygone mit Multipolygonen mischen, und Layer, die Linestrings oder Multilinestrings mit Multilinestrings mischen, automatisch zu befördern. Kann hilfreich sein, wenn Sie Shapefiles in PostGIS und andere Zieltreiber konvertieren, die strenge Prüfungen für Geometrietypen implementieren.
Mit anderen Worten, wenn Sie das PROMOTE_TO_MULTI
Flag verwenden, werden ALLE Ihre Features in mehrteilige Features konvertiert, auch wenn sie aus einem einzigen Teil bestehen. Wie von @LeeHachadoorian in den Kommentaren erwähnt - und ich bin sicher, dass die meisten zustimmen -, wird empfohlen, PROMOTE_TO_MULTI
das lockerere GEOMETRY
Flag vorzuziehen , da es den bewährten Methoden entspricht und die Feature-Geometrien in Ihrer Tabelle vereinheitlicht. Grundsätzlich sollte jeder Code, den Sie schreiben, nur mehrteilige Geometrien erwarten. Dies kann zugegebenermaßen sauberer sein und einen Teil der Entwicklung vereinfachen.
Allgemeiner Rat für jemanden, der Probleme mit dem POST-Import eines SHP hat
- Stellen Sie sicher, dass Ihre Pfade keine irren Zeichen enthalten und dass weder im Pfad noch im Dateinamen Tippfehler oder Rechtschreibfehler enthalten sind
- Stellen Sie, wie @ user1919 feststellte, sicher, dass Ihr Betriebssystembenutzer über ausreichende Berechtigungen für den Zugriff auf das Shapefile verfügt! Wie gezeigt, kann es hilfreich sein, das Shapefile in einer anderen Software wie QGIS zu öffnen. Wenn es in einer Software funktioniert, ist es nicht beschädigt und sollte in einer anderen Software funktionieren.
Erwägen Sie zunächst, den Befehl ogr2ogr auszuführen sudo
, um Berechtigungsprobleme auszuschließen, bis Sie sicher sind, dass Ihr Skript wie beabsichtigt funktioniert.
- Stellen Sie, wie @ user1919 erkannt hat, sicher, dass Ihr SQL-Benutzer über ausreichende Berechtigungen sowohl für die Datenbank, auf die sich Ihr Skript bezieht, als auch für die
spatial_ref_sys
Tabelle verfügt.
Ziehen Sie zunächst die Verwendung des PostGRESql-Superuser in Betracht, um SQL-Berechtigungsprobleme auszuschließen, bis Ihr Skript funktioniert. Wenn Ihr Skript mit dem Superuser funktioniert und dann mit einem bevorzugten Automatisierungsbenutzer fehlschlägt, wissen Sie, dass das Problem mit dem SQL-Benutzer zusammenhängt und nicht mit Ihren Daten oder Ihrer Umgebung (Installation von gdal / ogr usw.).
Setzen Sie die -nlt
Flagge entweder auf PROMOTE_TO_MULTI
oder GEOMETRY
. Da Shapefiles eine lockerere Konvention für Feature-Typen zulassen, müssen Sie Ihre Open Source-Dienstprogramme manchmal anweisen, unterhaltsamer zu sein :)
Wenn Sie PostgreSQL oder MySQL importieren, versuchen Einstellung -lco PRECISION=no
..fair Warnung, ich weiß nicht genau verstehen , was dieses Argument tut, aber hier ist das, was ich erlebt habe .. Wie Sie wissen, sind Shape - Dateien häufig die SHAPE_LENGTH
und SHAPE_AREA
Felder, und ich Ich habe manchmal bemerkt, dass ich bei mysteriösen Fehlern die Daten korrekt importieren kann, wenn ich diese Felder lösche. Wenn ich jedoch verwende -lco PRECISION=no
, kann ich die Daten importieren, ohne diese Felder löschen zu müssen. Ich empfehle, diesen Parameter als Fehlerbehebungsschritt zu verwenden, aber zu verstehen, welches Problem tatsächlich behoben wird, bevor Sie den Import in eine Produktionslösung akzeptieren.
Wenn Sie MySQL verwenden, beachten Sie, dass einige sehr große Feature-Geometrien den MySQL- max_allowed_packet
Parameter verletzen können . Weitere Informationen hierzu finden Sie in der Dokumentation zum MySQL-Treiber . Die Lösung besteht jedoch darin, Ihre MySQL-Konfiguration so zu ändern, dass ein Wert zulässig ist, der über dem Standardwert liegt.
Beispiel SHP to PostGIS-Importbefehl für ogr2ogr
Für alle Neulinge, die hier durchwandern, sehen die meisten meiner SHP to Post-Importe so aus, als würden sie ogr2ogr verwenden. Beachten Sie, dass ich Dateipfade / -namen in Anführungszeichen einfüge. Dies schützt vor Leerzeichen, seltsamen Zeichen und Zeilenumbrüchen im Terminal. Außerdem habe ich die meisten der oben diskutierten Argumente eingefügt, zusätzlich zu den Überschreibungen für das Geometrienamensfeld, das FID-Feld und der Layername:
ogr2ogr -f "PostgreSQL" "PG:host=127.0.0.1 user=myuser dbname=mydb password=mypassw0rd" "C:/path/to/some_shapefile.shp" -lco GEOMETRY_NAME=the_geom -lco FID=gid -lco PRECISION=no -nlt PROMOTE_TO_MULTI -nln new_layername -overwrite