Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Profils d'espèces] - Les paramètres en type integer ne sont pas adaptés aux projections non métriques #3167

Open
DonovanMaillard opened this issue Aug 24, 2024 · 8 comments
Labels

Comments

@DonovanMaillard
Copy link
Contributor

DonovanMaillard commented Aug 24, 2024

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
Copy link
Member

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
Copy link
Contributor Author

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

@TheoLechemia
Copy link
Member

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

@DonovanMaillard
Copy link
Contributor Author

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

@TheoLechemia
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants