[TAXREF] statuts présents uniquement pour la métropole

[dba-sig-sfepm]

Dans la table table taxref seul le statut correspondant à la colonne FR de taxref est importé (champ id_statut). Or cette valeur correspond au statut de présence en France métropolitaine. Pour travailler sur les autres territoires français il est donc nécessaire de réimporter les autres champs de présence de taxref (GF, MAR, GUA, ...).
Ils pourraient être intégrés directement dans la table de geonature.

[camillemonchicourt]

Voir #310

[dba-sig-sfepm]

Merci Camille mais Tout ce que j'ai lu semble faire allusion à une régionalisation de geonature. (d'ailleurs la présence même d'un champ geom_local à srid unique montre que toute l'application a été pensée comme ça). Or, et nous ne sommes peut-être pas les seuls, nous traitons les données nationales (métropole et outre-mer). Un choix de région à l'import de taxref n'est donc pas la solution pour nous. Pour l'instant j'ai importé les statuts de tous les territoires dans une table complémentaire et je m'en sers par jointure (surtout dans l'atlas).

[camillemonchicourt]

Oui je vois.
En effet cela a été conçu pour des contextes et des territoires assez locaux.

Mais il y a de plus en plus de contextes où il est nécessaire d'avoir des données métropole et DOM.

Dans ce cas-là la solution évoquée pour le SRID (à confirmer) est de configurer la projection de l'instance (et donc du champs geom_local) en 3857. Reste à voir les conséquences et solutions pour les calculs de surface et de distance avec une telle projection mondiale, des réflexions et analyses sur le sujet sont en cours.

Pour le sujet de ce ticket, et les tickets, en effet dans ces contextes, il ne s'agit de mettre les statuts d'un territoire ou d'un autre, mais de tous les territoires français.
En effet je crois comprendre que c'est possible actuellement de le faire, mais que cela n'est pas proposé par défaut, ni simple avec une commande. 🤔

[jpm-cbna]

Dans ce cas-là la solution évoquée pour le SRID (à confirmer) est de configurer la projection de l'instance (et donc du champs geom_local) en 3857. Reste à voir les conséquences et solutions pour les calculs de surface et de distance avec une telle projection mondiale, des réflexions et analyses sur le sujet sont en cours.

A priori Postgresql supporte le stockage dans un champ GEOMETRY avec le SRID que l'on désire si on ne spécifie pas sa valeur au moment de la création de la colonne. Du coup, est ce que l'on ne pourrait pas stocker des géométries non projetés et utiliser le SRID qui va bien pour la géométrie correspondante dans le champ geom_local ?

Je pose la question mais je suis presque certain que cela impacte beaucoup d'éléments de GeoNature.

Nous avons également ce besoin avec des données provenant du Liban et de St Pierre et Miquelon.