Absence de .cpg/impossibilité d'importer la couche parcelle avec PostGis 2.2

[Az8th]

Bonjour,

J'utilise les couches bâtiments et parcelles et ai besoin de les uploader sur une base de donnée afin de les utiliser dans mon environnement de travail. Pour cela j'utilise PostGis (v2.2), qui malheureusement échoue l'importation à la moindre erreur dans le fichier, et j'en ai quelques unes avec votre jeu de données.

Premièrement, l'absence du fichier .cpg peut provoquer des soucis si on ne sait pas comment les données sont encodées, et je n'ai trouvé cette information nul part. (J'ai essayé UTF-8 et LATIN1) Je pense qu'il serait judicieux de l'ajouter à chacune des couches présentes, en effet même si des éditeurs tel que qGIS peuvent le déduire, ce n'est pas le cas de tous les logiciels, et par conséquent cela peut engendrer ce genre d'erreur :

Importing with configuration: building, public, geom, C:\Users[username]\Desktop\test_upload\01\building.shp, mode=a, dump=1, simple=0, geography=0, index=0, shape=1, srid=[an_id] Shapefile type: Polygon PostGIS type: MULTIPOLYGON[2] Unable to convert data value to UTF-8 (iconv reports "Illegal byte sequence"). Current encoding is "UTF-8". Try one of the values described at http://www.postgresql.org/docs/current/static/multibyte.html.

Ensuite, j'obtiens l'erreur suivante uniquement avec la couche parcelles:

Importing with configuration: parcelles, public, geom, C:\Users[username]\Desktop\test_upload\01\parcelles.shp, mode=c, dump=1, simple=0, geography=0, index=1, shape=1, srid=[an_id] Shapefile type: Polygon PostGIS type: MULTIPOLYGON[2] Error reading shape object 1329574

Cette erreur se produit sur tous les départements (ici, l'Ain), toujours à l'avant dernier objet, je soupçonne donc un même problème d'encodage erroné, ou alors un souci dans le footer. En tout cas cela ressemble en tout point à ce ticket : https://github.com/etalab/cadastre/issues/58 Pourriez vous investiguer s'il vous plaît ?

Merci à vous

[Az8th]

A noter qu'en important le shapefile dans QGis et en le réenregistrant, le fichier ne pose plus de problème, et pèse même moins lourd. Les données sont donc bien exploitables, mais il doit y avoir une erreur de syntaxe/encodage avec la conversion depuis geojson.

[Az8th]

Autre que l'encodage, l'erreur pourrai aussi venir du fait que les shapefiles ne peuvent être des couches formées que par un unique type de géométries (point, polygone...), contrairement au format GeoJSON. Hors il est étrange que PostGis fait état d'un multipolygone dans une couche composée de polygones, par conséquent il se peut que votre script de conversion force la présence d'un multipolygone dans une couche de polygone, ce qui pourrai causer cette erreur. J'étais tombé sur un bout de code de QGis gérant ce genre de cas en ignorant tout simplement les "intrus" (et en éclatant les géométries multiples) en cherchant des infos sur une fonction mal documentée.

[jdesboeufs]

Les parcelles sont enregistrées en multipolygones car il y a des parcelles multipolygones en Alsace. Par contre pour le moment je n'ai pas trouvé la source du problème.

[jdesboeufs]

Je suis preneur des lignes de commandes et versions des outils qui permettent de reproduire ce problème.

Cela peut paraître curieux mais je ne suis pas un utilisateur régulier de PostGIS et QGIS 🙃

[Az8th]

Les parcelles sont enregistrées en multipolygones car il y a des parcelles multipolygones en Alsace. Par contre pour le moment je n'ai pas trouvé la source du problème.

Du coup toutes les géométries sont elles transformées en multipolygones? Et cela s'applique t'il seulement à l'Alsace ou à toute la France?

Je suis preneur des lignes de commandes et versions des outils qui permettent de reproduire ce problème. Cela peut paraître curieux mais je ne suis pas un utilisateur régulier de PostGIS et QGIS upside_down_face

Je comprends tout à fait :smiley:

L'import est fait en utilisant la commande suivante (l'erreur est également présente sur la version graphique de PostGIS) : shp2pgsql -s SRID SHAPEFILE.shp SCHEMA.TABLE | psql -h HOST -d DATABASE -U USER

Après par souci de rapidité, (requêtes beaucoup trop longues) nous allons migrer vers du SQLite. Si le même problème se montre, je vous le ferrai savoir.

Cependant outre ce problème d'import, est-il possible pour vous d'ajouter les fichiers .cpg (encodage) pour les futurs millésimes?

[PierreNansot]

Honnêtement, je doute qu'il y a un gain de performance à passer à SQLite. C'est gdal qui fait le plus gros du boulot dans l'import. Personnellement, j'importe quasiment tout ce qui est proposé par etalab. A coup de demi-million d'insert par requête, j'ai pas spécialement à me plaindre du temps que cela prend.

Je mets ci-dessous un bout de mon script python.

def json_to_postgis(file_name, table, first):
    file_location = "input/" + file_name
    bash = 'ogr2ogr -f "PostgreSQL" --config PG_USE_COPY YES PG:"host=' + host + ' port=' + port + \
           ' dbname=' + dbname + ' user=' + user + ' password=' + password + '" "/vsigzip/' + file_location + \
           '" -progress -nln ' + table
    if first:
        bash = bash + ' -nlt GEOMETRY -gt 500000'
    else:
        bash = bash + ' -append -gt 500000'

[ThomasG77]

Ferme. Trop ancien. Réouvrez, commentez si toujours d'actualité et surtout bloquant