[Projection] - Possibilité d'avoir des instances "mondialisées" Métropole + DOM-TOM

[DonovanMaillard]

Version
toutes

Description du bug
Les paramètres des profils d'espèces, en particulier les "spatial_precision" sont de type integer. C'est très bien adapté en mètres (2000 par défaut), mais si on utilise une projection locale qui n'est pas en mètres (wgs84 par exemple), le paramètre doit pouvoir se configurer par une variable de type numeric. (0,02° par exemple pour avoir quelque chose du même ordre de grandeur).

Comportement attendu
Modifier le type des champs pour passer à un type "numeric"

Implique également de mettre à jour la fonction get_parameters (qui attend un integer), et donc de recréer les vues et VM qui ont des dépendances avec ces objets en cascade.

J'ai les scripts de mon coté, je pourrai partager pour en faire une migration alembic sans souci.

Comment reproduire

Logs

[camillemonchicourt]

Je ne pense pas que cela soit une bonne idée d'utiliser une projection de stockage des données non métrique, ça pose toujours des soucis de calcul de longueur et autres.

[DonovanMaillard]

oui, mais reprojeter en lambert des données des dom-tom pose question aussi...

[TheoLechemia]

Il y a des projections métriques adaptées au DOM aussi !

[DonovanMaillard]

Oui mais adapté à métro + dom ? Je connais pas tellement les projections...

[TheoLechemia]

Je crois que le 3857 peut faire l'affaire dans ce genre de cas. Mais c'est moins précis qu'une projection locale forcément

[gildeluermoz]

Est-ce que conserver "spatial_precision" en mètre et demander à l'application de convertir cette distance dans la projection locale de l'instance serait envisageable ?

[camillemonchicourt]

Je crois que le 3857 peut faire l'affaire dans ce genre de cas. Mais c'est moins précis qu'une projection locale forcément.

Oui j'avais en tête que ^pour une instance mondiale, on pouvait partir sur 3857, plutôt que 4326, pour rester en mètre. Mais je ne sais pas si cela a des conséquences en terme de précision de la localisation des données.

[DonovanMaillard]

Je suis en train de passer une instance en 4326, je vais me reposer cette question avant d'aller au bout et tester.

[DonovanMaillard]

Je reviens vers vous après un petit moment, et après avoir creusé un peu le sujet :)

Le 3857 est certes exprimé en système métrique, mais le mode de projection est le même que le WGS84, qui préserve les angles mais pas les distances et les surfaces. On aura donc les mêmes déformations en 4326 et en 3857 quand on s'éloignera de l'équateur. Seuls les systèmes locaux semblent dont adaptés pour faire les calculs de distances et de surfaces, que ca soit dans des modules comme OccHab ou dans les buffer des profils d'espèces.

Pour avoir une instance "mondiale", ou en tous cas DOM-TOM + Métropole, il faudrait donc réussir à dissocier le pur stockage des données (modules de saisie, synthèse, ref_geo etc) en projection globale (que ça soit 4326 ou 3857) d'une part, et leur exploitation dans des calculs (systèmes locaux : lambert 93, UTM etc) pour les surfaces et distances.

Si on veut avoir des instances "mondiales" avec des calculs de distances et de surfaces précis, il faudrait : soit tout stocker en WGS et convertir les données dans leur bon fuseau UTM pour les calculs. Soit tout stocker et analyser directement dans son fuseau UTM en fonction de ce qu'on préfère, mais avec des tables qui peuvent stocker des géométries dans différents SRID donc un peu plus tordu pour les contraintes et typage des champs géométrie.

La SHF se lance dans l'exercice, avec des données stockées en 4326 sur l'ensemble du globe. On ne remet pas encore en place les profils actuellement mais l'idée serait de convertir les données en UTM au moment du calcul uniquement, puis retourner le résultat en 4326 pour permettre les intersections avec les données en synthèse notamment.

[camillemonchicourt]

OK OK merci pour cette analyse.
Je ne pense pas qu'il soit possible ni souhaitable d'avoir des géométries dans un même champs mais avec des projections différentes, et cela compliquerait pas mal de choses.
Donc à voir si les autres pistes sont plus viables.