Comme vous l'avez découvert par essais et erreurs, il y avait quelques problèmes lancinants que vous deviez résoudre, le dernier ayant été résolu en utilisant l' argument -nlt GEOMETRY
* d'ogr2ogr .
* Notez la recommandation dans le commentaire de @ LeeHachadoorian qui doit -nlt PROMOTE_TO_MULTI
être utilisée comme solution par défaut, plutôt que nlt GEOMETRY
, car la première promeut les meilleures pratiques en plus des avantages accessoires.
Autorisations utilisateur et messages d'erreur
Tout d'abord, ogr2ogr n'a pas pu ouvrir votre fichier de formes et vous avez réalisé que des problèmes d'autorisations affectaient en fait l'utilisateur du système d'exploitation accédant à votre fichier de formes. Mais il y a une leçon importante ici pour les autres, en particulier, le message d'erreur d'ogr2ogr sur ce point était trompeur! En effet, l'un des premiers commentateurs pensait que votre fichier de formes n'était pas valide, et il est vrai que ma première supposition était qu'il y avait probablement une erreur / faute de frappe dans le chemin / nom de fichier, ou qu'il pouvait y avoir un caractère non conventionnel dans le chemin du fichier - comme un l'espace - qui brisait la capacité d'ogr2ogr à pointer vers le fichier de formes. Comme vous l'avez découvert, ce n'était en fait qu'un problème avec les autorisations des utilisateurs. Parce que le message d'erreur crée un hareng rouge, c'est une possibilité que les autres doivent garder à l'esprit. :)
Privilèges utilisateur SQL et échecs mystères
J'aurais été bloqué par votre deuxième erreur pendant un certain temps, mais en testant votre utilisateur SQL avec un autre utilitaire d'importation (shp2pgsql), qui était intelligent, vous avez reçu un message d'erreur plus précis et donné à votre utilisateur SQL les privilèges nécessaires sur la spatial_ref_sys
table. Ainsi, quelqu'un qui a du mal à faire fonctionner correctement son instruction d'importation ogr2ogr doit s'assurer que son utilisateur SQL dispose de privilèges suffisants sur la base de données elle - même et sur la table 'spatial_ref_sys'.
Types de géométrie mixte et meilleures pratiques
Le dernier obstacle que vous avez rencontré semble lié au fait que les fichiers de formes permettent aux géométries à la fois uniques et multiples de coexister dans le même ensemble de données / fichier. Il est considéré comme une mauvaise pratique de mélanger les types de géométrie dans la même table, même pour un seul / plusieurs parties du même type d'entité, et par défaut, les lecteurs open source de votre chaîne d'outils essaieront de vous protéger contre le mélange des types de géométrie. Heureusement, cependant, ils vous offrent quelques options. Initialement, j'ai recommandé de définir l' argument -nlt GEOMETRY
* sur votre instruction ogr2ogr, ce qui vous a permis d'importer votre jeu de données de polygones malgré la convention plus lâche d'ESRI. Soyez avisé cependant, cela signifie que vous avez probablement à la fois des géométries en une seule partie et en plusieurs parties dans votre table, et cela peut créer d'autres maux de tête pour votre futur!
Il convient de mentionner que ogr2ogr a une autre -nlt
option à considérer, à savoir PROMOTE_TO_MULTI
. Pour citer la documentation ..
À partir de GDAL 1.10, PROMOTE_TO_MULTI peut être utilisé pour promouvoir automatiquement des couches qui mélangent des polygones ou des multipolygones en multipolygones, et des couches qui mélangent des chaînes de lignes ou des chaînes multiples en chaînes multiples. Peut être utile lors de la conversion de fichiers de formes en PostGIS et autres pilotes cibles qui implémentent des contrôles stricts pour les types de géométrie.
En d'autres termes, si vous utilisez l' PROMOTE_TO_MULTI
indicateur, TOUTES vos fonctionnalités seront converties en fonctionnalités en plusieurs parties, même lorsqu'elles sont constituées d'une seule pièce. Comme indiqué par @LeeHachadoorian dans les commentaires - et je suis sûr que la plupart seraient d'accord - il est conseillé de préférer PROMOTE_TO_MULTI
le GEOMETRY
drapeau plus lâche , car il est conforme aux meilleures pratiques, unifiant les géométries des entités dans votre table. Fondamentalement, tout code que vous écrivez doit simplement attendre des géométries en plusieurs parties. Certes, cela peut être plus propre et simplifier une partie du développement.
Conseils génériques pour une personne ayant des problèmes avec un SHP pour importer des POST
- Assurez-vous que vos chemins ne contiennent aucun caractère génial et qu'il n'y a pas de fautes de frappe ou d'orthographe dans le chemin ou le nom de fichier
- Comme l'a découvert @ user1919, assurez-vous que votre utilisateur du système d'exploitation dispose de privilèges suffisants pour accéder au fichier de formes! Comme ils l'ont démontré, cela peut aider à essayer d'ouvrir le fichier de formes dans un autre logiciel, comme QGIS - s'il fonctionne dans un logiciel, il n'est pas corrompu et devrait fonctionner dans d'autres logiciels.
Dans un premier temps, envisagez d'exécuter votre commande ogr2ogr sudo
pour exclure les problèmes d'autorisations jusqu'à ce que vous soyez certain que votre script fonctionne comme prévu.
- Aussi, comme @ user1919 l'a réalisé, assurez-vous que votre utilisateur SQL dispose de privilèges suffisants sur la base de données ciblée par votre script, ainsi que sur la
spatial_ref_sys
table.
Encore une fois, dans un premier temps, envisagez d'utiliser le super utilisateur PostGRESql ici pour exclure les problèmes de privilèges SQL jusqu'à ce que votre script fonctionne. Si votre script fonctionne avec le superutilisateur puis échoue avec un utilisateur d'automatisation préféré, vous savez que le problème est lié à l'utilisateur SQL et non à vos données ou à votre environnement (installation de gdal / ogr, etc.)
Essayez de définir le -nlt
drapeau sur PROMOTE_TO_MULTI
ou GEOMETRY
. Étant donné que les fichiers de formes permettent une convention de type de fonctionnalité plus lâche, vous devez parfois demander à vos utilitaires open source d'être plus accommodants :)
Si vous importez à MySQL ou PostGreSQL, essayez de -lco PRECISION=no
..fair avertissement, je ne comprends pas exactement ce que cet argument fait, mais voici ce que j'ai vécu .. Comme vous le savez, shapefiles incluent souvent les SHAPE_LENGTH
et les SHAPE_AREA
champs, et je 'ai parfois remarqué lorsque je rencontrais des échecs mystères, si je supprime ces champs, je peux obtenir les données à importer correctement. Cependant, si j'utilise -lco PRECISION=no
, je peux obtenir les données à importer sans avoir à supprimer ces champs. Ma recommandation est d'utiliser ce paramètre comme étape de dépannage, mais pour comprendre quel problème il résout vraiment avant d'accepter l'importation dans une solution de production.
Enfin, si vous utilisez MySQL, gardez à l'esprit que de très grandes géométries d'entités peuvent offenser le max_allowed_packet
paramètre de MySQL . Vous pouvez en savoir plus à ce sujet dans la documentation du pilote MySQL .. mais la solution consiste à modifier votre configuration MySQL pour autoriser une valeur supérieure à la valeur par défaut.
Exemple de commande d'importation SHP vers PostGIS pour ogr2ogr
Pour le bien des débutants qui pourraient se promener ici, voici à quoi ressemblent la plupart de mes importations SHP to Post en utilisant ogr2ogr. Notez que j'encapsule les chemins / noms de fichier entre guillemets, cela protège contre les espaces, les caractères étranges et les sauts de ligne sur le terminal. J'ai également inclus la plupart des arguments discutés ci-dessus, en plus des remplacements pour le champ de nom de la géométrie, le Champ FID et nom de couche:
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