Hello,
@Marc, justement je pointais l'attention sur 'il ne faut pas mixer', on
est donc daccord J
Sinon je te rejoins, on pourrait séparer les éléments visibles
basiquement (sans recherche approfondie) et les inclure par défaut dans
le survey:date. Pour les éléments plus spécifiques/+ approf
Bonjour,
Vu que l'inventaire semble complet,je propose de fusionner :
source_date et date:source en faveur du tag majoritaire source:date
date:survey en faveur du tag majoritaire survey:date
ok ? objection ?
Cordialement,
Marc
Le 12. 09. 17 à 14:01, Marc M. a écrit :
> @tous : il ne manque aucu
@tous : il ne manque aucun besoin avec ces 3 type survey <> fonctionnel
<> source externe ?
@Christian l'outil est prometteur.
C'est un bon exemple d'interface simple même si quelques détails
serraient utile (valider une porte d'entrée, pas sur de l'utilité).
Je vais e tester un peu plus pour pr
La webapp geocropping rend ce process de mise à jour d'une date de contrôle
sur terrain très simple et pas technique du tout.
A voir ici: https://geocropping.xsalto.com/
Le 11 septembre 2017 à 18:33, Violaine Doutreleau
a écrit :
> Bonjour Marc,
>
> Pour moi la difficulté c'est qu'il ne faudrai
Bonjour Marc,
Pour moi la difficulté c'est qu'il ne faudrait pas mixer la source d'une
information (je suis ok pour ajouter une info de date en fonction de la
source de données), par le check_date ou operational_status:date, qui
relève plutôt de la validation de données. J'entends : la donnée
Suite à une discussion à propos des dates, j'ai été faire un tour
sur le wiki et taginfo. La problème était simple mais comme souvent
il y a une grande diversité de mise en place.
Il y a, si j'ai oublié personne, 3 grand besoins :
- la date où un objet a été vu la dernière fois sur le terrain
sur
6 matches
Mail list logo