Prise en compte d'autres SRID (process#4)
AudreyEnGuyane opened this issue · 2 comments
Re-Bonjour à tous,
Pour faire suite au message #387, nous avons quand même réalisé des tests avec des données en WGS84.
Nous passons tous les filtres/tests (correspondance des champs, des nomenclatures et bounding_box) jusqu'à l'étape 4 "Import des données" mais c'est l'importation elle-même qui coince et il s'agirait d'un problème de SRID.
Si je n'arrive pas à voir la totalité du message d'erreur (reporté ci-après), il semblerait que la requête d'importation s'acharne à utiliser le lambert93 (srid 2154) comme système de projection de the_geom_local:
"(psycopg2.errors.InvalidParameterValue) ERREUR: Geometry SRID (2972) does not match column SRID (2154)
[SQL: BEGIN;
ALTER TABLE gn_synthese.synthese DISABLE TRIGGER tri_meta_dates_change_synthese;
ALTER TABLE gn_synthese.synthese DISABLE TRIGGER tri_insert_cor_area_synthese;
INSERT INTO gn_synthese.synthese (................................ "
Lors de la configuration de GeoNature, nous avons installé avec le SRID de référence de notre territoire (2972) qui est stocké dans gn_commons.t_parameters (id_parameter = 3). Donc problème quand on essaie d'insérer des données geo en 2154 dans un champ en 2972...
Le script d'import des données depuis le module Import n'exploite pas ce paramètre?
Où va-t-il chercher le SRID local?
Avec Joël, on a trouvé la solution qu'on vous communique au cas où:
Le paramètre local_srid n'est pas récupéré dans la table t_parameters mais dans le fichier geonature_config.toml où nous avions oublié de modifier ce paramètre.
Peut-être que la prise en compte systématique du local_srid depuis la table t_parameters pourrait être systématique dans la prochaine version du module?
Pour simplifier les choses et éviter ce genre de soucis, dans la 2.10 à venir, ces 2 paramètres de SRID local (dans la table des paramètres et dans la conf de GN) ont été supprimés.
On récupère le SRID local dynamiquement en analysant le champs ref_geo.l_areas.geom.