Bonjour, J'utilise OGR2OGR pour importer la BDTOPO sur l'emprise du Gard depuis son format GPKG vers notre base PG. On est en train de monter les versions des briques de notre stack data et avec la version 3.13 de GDAL j'ai un échec d'import alors que cela fonctionne correctement en 3.6 (et a priori en 3.11 aussi). J'ai tourné pas mal de temps autour de ce problème et avec l'aide de Gemini j'ai pu trouver une solution en activant le paramètre LIST_ALL_TABLES à NO. Je m'étais d'abord tourné vers l'activation du paramètre -skipfailures comme l'indique le message d'erreur. Le problème de ce paramètre est qu'il implique l'abandon du traitement des données par lot. Dès lors, chaque ligne est importée unitairement ce qui rend l'import des gros thèmes (troncon_de_route, batiment) vraiment trop long. Je vous copie-colle ici le rapport d'analyse généré par Gemini, je n'ai pas pu valider à la lecture de la doc GDAL que la rupture de fonctionnement se situe à partir de la version 3.12 comme il l'indique. En effet, la doc parle de la RFC 97 dès la version 3.9 or comme indiqué plus haut l'import semble ok en 3.11 donc j'ai des doutes. En tout cas, il semble bien y avoir un pb. Rapport Gemini Sujet : Incompatibilité des GeoPackages avec GDAL 3.12+ / 3.13 (Erreur de typage 'character varying') Bonjour à l'équipe et à la communauté, Je me permets de vous signaler une régression technique lors de l'importation de vos GeoPackages (GPKG) dans des bases PostgreSQL à l'aide des versions récentes de l'outil ogr2ogr (GDAL 3.12 et versions supérieures / 3.13). L'import global échoue désormais systématiquement avec le message d'erreur fatal suivant : ERROR 1: Error retrieving the source layer definition Origine du problème En analysant les logs, on constate la présence de l'avertissement : Warning 1: Field format 'character varying' not supported Le problème provient du fait qu'une ou plusieurs tables incluses dans le GeoPackage (très probablement une table liée à un export PostgreSQL brut, ou la table de styles QGIS layer_styles) contiennent des colonnes typées en character varying. Selon les spécifications officielles de l'OGC pour le standard GeoPackage, ce type de données n'est pas autorisé (les seuls types textuels valides dans SQLite/GPKG sont TEXT ou MEDIUMTEXT). Pourquoi cela bloque maintenant ? Sur GDAL ≤ 3.11 : L'outil était tolérant, émettait un simple warning et convertissait le champ à la volée. Depuis GDAL 3.12/3.13 : Suite à des évolutions majeures sur la validation et le verrouillage strict des schémas (mécanisme de sealing introduit via la RFC 97), GDAL refuse désormais catégoriquement de valider et de lire une couche dont la définition de champ viole le standard du format source. La commande s'interrompt donc immédiatement. Comment reproduire / mettre en évidence l'anomalie ? En ouvrant le GeoPackage avec un outil de gestion SQL et en interrogeant les tables systèmes, on peut lister les tables non conformes via cette requête : sql SELECT tbl_name, sql FROM sqlite_master WHERE type='table' AND sql LIKE '%character varying%'; Solution de contournement actuelle (pour les utilisateurs) Pour ceux qui rencontrent le problème, j'ai pu contourner le blocage en forçant GDAL à ignorer les tables système non géographiques grâce à l'option de configuration suivante, ce qui permet de conserver l'import par lot performant : bash --oo LIST_ALL_TABLES=NO Demande de correction Serait-il possible de modifier votre chaîne de traitement / script d'export afin de vous assurer que les types spécifiques à PostgreSQL (comme character varying) soient proprement traduits en TEXT dans le GeoPackage final ? Cela garantirait la pleine compatibilité de vos données avec les versions modernes de GDAL/ogr2ogr sans nécessiter de contournement.
Français