[Erreur 500] : Filtre geometry lorsque l'export est définie en 2154

[cen-cgeier]

Bonjour à tous !
Export version : 1.8.0

• Contexte :
  J'ai programmer un export avec une projection 2154 et j'ai tenté de réaliser un filtre géographique via l'option d'intersection polygonale utilisable par l'argument geometry=

• Logs API :

{"code": 500, "description": "(psycopg2.errors.InternalError_) ERREUR:  ST_Intersects: Operation on mixed SRID geometries (MultiPolygon,
 2154) != (Polygon, 4326)\n\n[SQL: SELECT count(*) AS count_1 \nFROM (SELECT gn_exports.v_synthese_zh_rhomeosite.id_zh AS 
gn_exports_v_synthese_zh_rhomeosite_id_zh, gn_exports.v_synthese_zh_rhomeosite.\"NAME\" AS 
\"gn_exports_v_synthese_zh_rhomeosite_NAME\", gn_exports.v_synthese_zh_rhomeosite.\"REFERENT\" AS 
\"gn_exports_v_synthese_zh_rhomeosite_REFERENT\", gn_exports.v_synthese_zh_rhomeosite.\"ORG\" AS 
\"gn_exports_v_synthese_zh_rhomeosite_ORG\", gn_exports.v_synthese_zh_rhomeosite.\"TYPE\" AS 
\"gn_exports_v_synthese_zh_rhomeosite_TYPE\", gn_exports.v_synthese_zh_rhomeosite.\"ODONATE\" AS 
\"gn_exports_v_synthese_zh_rhomeosite_ODONATE\", gn_exports.v_synthese_zh_rhomeosite.geom AS 
gn_exports_v_synthese_zh_rhomeosite_geom \nFROM gn_exports.v_synthese_zh_rhomeosite \nWHERE 
ST_Intersects(gn_exports.v_synthese_zh_rhomeosite.geom, ST_GeomFromText(%(ST_GeomFromText_1)s, %(ST_GeomFromText_2)s)) ORDER 
BY gn_exports.v_synthese_zh_rhomeosite.id_zh \n LIMIT %(param_1)s OFFSET %(param_2)s) AS anon_1]\n[parameters: 
{'ST_GeomFromText_1': 'Polygon ((934472.03314059763215482 6466146.93896909337490797, 942237.00141640822403133 
6466146.9389690924435854, 942237.00141640822403133 6476652.48428342491388321, 934472.03314059763215482 
6476652.48428342677652836, 934472.03314059763215482 6466146.93896909337490797))', 'ST_GeomFromText_2': 4326, 'param_1': 1000, 
'param_2': 0}]\n(Background on this error at: https://sqlalche.me/e/14/2j85)", "name": "Internal Server Error", "request_id": "34a422b2-
cdd8-4d1e-a956-e230c584af17"}

Il semble que la géométrie utilisée est forcée en 4326 alors que les coordonnées sont en 2154.

• [Proposition] correction du bug :
  Ajouter l'argument self.geometry_srid lors de l'utilisation de la fonction GenericQueryGeo, à la ligne 152.
  Ça résout ce problème, mais je ne sais pas si il y a des dysfonctionnement en cascade.. A tester

[camillemonchicourt]

OK, c'est possible que le paramètre geometry= que l'on peut passer sur les API du module Export a peut-être été rendu possible en 4326.
C'est ce qui est le plus courant, mais pourquoi pas permettre de gérer la projection de la géométrie, mais il faudra que ceux qui interrogent l'API sachent la projection utilisée...

Sinon il faut fournir le champs de géométrie de l'export en 4326. 😇

[cen-cgeier]

J'ai l'impression qu'avec l'évolution que je propose, la projection du champs géométrie fournie se basera sur celle paramétrée dans l'export (comme souhaitée par le comportement théorique).
Tandis que pour le moment, la projection utilisée pour le champs géométrie fournie est le 4326 strict. 🤔

[jacquesfize]

Dans sa spécification, les coordonnées stockées dans un GeoJSON doivent être dans la projection WGS84 🤔 Toutefois, il est important que l'export puisse fonctionner même quand la colonne de la vue est dans une autre projection.