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

[ENTRANCE CAVE] Improvement of depth / height difference #879

Open
bsoufflet opened this issue May 26, 2022 · 5 comments
Open

[ENTRANCE CAVE] Improvement of depth / height difference #879

bsoufflet opened this issue May 26, 2022 · 5 comments

Comments

@bsoufflet
Copy link
Contributor

Request from @BTHOM send by email :
"Profondeur" devrait plutôt être remplacé par "Dénivelé". Et la valeur indiquée serait alors complétée à coté ou en dessous par une mention classique (- P, + A) où "P" est la profondeur maxi depuis la cote zéro d'entrée et où "A" est la remontée maxi depuis la même cote zéro. Ainsi, en cas de cavité/réseau à entrées multiples, chaque entrée a un couple (-P, +A) unique, mais toutes ont le même dénivelé "D" qui est l'extension verticale maximale du réseau.

@Clm-Roig
Copy link
Member

J'en profite pour mentionner l'existence de l'attribut max_depth dans la table t_cave qui n'est, pour l'instant, jamais utilisé : peut-être faudrait-il le supprimer ?

Sinon, pour répondre à l'issue initiale, rajouter ces attributs (P et A) dans la table t_entrance serait envisageable sans souci je pense.

@bsoufflet
Copy link
Contributor Author

@BTHOM @Clm-Roig @urien : En y réfléchissant, si l'on souhaite automatiser au maximum il me semble que l'idéal pourait etre :

  • stocker sur la cave le dénivelé total (point le plus haut dans a cavité au point le plus bas)
  • stocker sur chaque entrée de la cave sa "cote" par rapport au dénivelé total de la cave.

Si on prend l'exemple d'une cave avec un denivele total de 100m

  • si on a une entrée avec la cote 0 alors elel serait situé au point le plus haut de la cave et pourrait générer le (-P, +A) -> (-100, +0)
  • si on a une entrée avec la cote -10m alors on pourrait générer le (-P, +A) -> (-90, +10)
  • Si des explorations permettent de découvrir de nouveaux réseaux au fond et d'augmenter le dénivelé total, alors rien à faire sur les entrées.
  • Si des explorations permettent de découvrir de nouveaux réseaux remontants et d'augmenter le dénivelé total, alors il faudra corriger les cotes de toutes les entrées (mais c'est un cas moins fréquent).

VOus en pensez quoi ?

@Clm-Roig : On utilise quoi pour la profondeur dénivelé actuellement ? Ce max_depth je en sais plus pourquoi il est là... @urien ?

@Clm-Roig
Copy link
Member

On utilise depth pour la profondeur d'un réseau.

@BTHOM
Copy link

BTHOM commented May 30, 2022 via email

@urien
Copy link
Contributor

urien commented May 30, 2022

Dans karstlink, et donc dans le système d'import de csv qui a été mis en place nous avons
https://ontology.uis-speleo.org/ontology/#verticalExtent
qui correspond a notre depth

https://ontology.uis-speleo.org/ontology/#extentAboveEntrance
https://ontology.uis-speleo.org/ontology/#extentBelowEntrance
qui correspondent a max_depth et min_depth qui existent dans la base mais qui n'ont jamais été utilisé

La difficulté c'est que le champ actuel est attaché à la cavité et a son entrée s'il n'y en a qu'une
Les deux nouveaux champs sont associés à l'entrée et il doit y avoir une cohérence avec le champ actuel. cette cohérence est simple a gérer quand la cave et associé a une seule entrance, par contre je ne vois pas comment procéder pour un réseau, sauf à faire des mises à jour manuelles.

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

No branches or pull requests

4 participants