[OSM-talk-fr] les dates de terrain, de test fonctionnel, d'import, de source

marc marc marc_marc_irc at hotmail.com
Ven 29 Sep 15:32:28 UTC 2017


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 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 proposer des améliorations.
> 
> @Violaine
> que veux-tu dire par mixer ? ce serrait au contraire plus clair si on 
> fait 3 catégories bien distincte comparé par exemple au tag check_date 
> où il est impossible de savoir qu'est-ce qui a été précisément vérifié 
> (la position, l’existence, le fonctionnel)
> Exemple fictif : les bornes incendies d'une commune
> Lors de l'import on précise sur le changeset source=lacommune 
> source:date=2015/01/01
> Si quelqu'un voit la borne sur le terrain et veux préciser la date,
> il peux rajouter survey:date=2017/09/12 (sinon on suppose que c'est
> une date proche de la modif, pas besoin de raffiner cela à l’extrême)
> Si un technicien teste la borne comme fonctionnelle, on peux encoder 
> cette information avec operational_status=operating 
> operational_status:date=2017/09/12
> 
> Pour l'étendue de la vérification, c'est justement le reproche que je 
> fais à check_date. on ne sait pas si cela signifie que l'objet a été
> vu sur le terrain, ou si l'objet a été comparé avec une liste opendata
> ou s'il s'agit d'un test fonctionnel.
> Je pense aussi que cela n'a de sens que sur des objets assez précis
> que pour déduire que la vérification est complète.
> On peux dire qu'on a vu un arrêt de bus ou testé une borne.
> Prétendre la même chose sur un hôpital me semble délicat.
> Etait-ce son existence ? son nom ? tout ces tags ?
> Rien n’empêche de préciser capacity:bed:date par exemple
> Peut-être faudrait-il préciser qu'un survey:date par exemple concerne 
> tous les tags d'un objet. mais quid des infos provenant d'un import mais 
> qui sont invérifiable sur le terrain (par exemple le diamètre du tuyau 
> d'alimentation d'une borne lorsque l'info n'est pas sur la plaque) ?
> Je n'ai pas de solution pour améliorer le sens.
> Dupliquer tout les tags avec une date me semble impossible en pratique
> vu la difficulté qu'il y a avec des schémas beaucoup plus simple.
> 
> Le 11. 09. 17 à 21:21, Christian Quest a écrit :
>> 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 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 est déjà créée, je repasse x jours
>>     après sa création pour dire qu'elle est toujours valide. Healthsites
>>     prévoit de faire ça sur la thématique santé... Par contre j'aime
>>     beaucoup l'idée car on pourrait imaginer de la demande de validation
>>     de données si le check_date est trop éloigné de la date du jour aux
>>     utilisateurs de gps... Et ça pourrait donner un sacré coup de 
>> pouce ...
>>
>>     Par contre j'ai le sentiment que ce n'est pas vraiment la place de
>>     la validation, mais d'une base extérieure? Dailleurs ça risque
>>     d'être trop tech pour des utilisateurs lambdas d'OSM, et pourtant
>>     des informations faciles à donner par n'importe qui.
>>
>>     Sinon, une autre difficulté que je trouve c'est qu'il faudrait quasi
>>     autant de check_date, que de tags, ou alors définir les éléments que
>>     l'on souhaite vérifier. Non? Par exemple pour les centre de santés,
>>     c'est pas évident de tout contrôler d'un coup si on est un
>>     utilisateur lambda  (pas aussi simple de donner le nombre de staffs
>>     par exemple)
>>
>>     Juste mes réflexions...
>>
>>     A bientôt,
>>
>>     V
>>
>>
>>     Le 06/09/2017 à 00:16, marc marc a écrit :
>>>     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
>>>     survey:date avec toutes les variantes d'ordre et de caractère
>>>     de séparation
>>>     Ce serrait selon moi le tag à utiliser pour des projets comme 
>>> jungle bus
>>>     où certains veulent pouvoir éventuellement vérifier l’existence
>>>     d'un objet qui n'a plus été vu depuis X temps.
>>>
>>>     - la propal sur les bornes a fait sortir un 2ieme besoin, celui
>>>     qui concerne les équipements "technique" ou "voir" ne suffit pas
>>>     à dire que cela fonctionne. exemple : le pompier à l’œuvre sur
>>>     la propal des bornes qui voudrait pouvoir tester les bornes.
>>>     Initialement, c'était prévu d'utiliser check_date
>>>     le nom n'est pas terrible, le "_" encore moins mais il a
>>>     l'avantage d'exister
>>>     A la relecture, le wiki ne précisant pas qu'est ce qui est vérifié,
>>>     je me demande s'il ne serrait pas mieux d'utiliser
>>>     operational_status:date qui a l'avantage d'être parfaitement clair.
>>>
>>>     - source:date : la date de la source des données par exemple 
>>> utilisée
>>>     lors d'un import mais aussi celle de l'imagerie lorsque connue.
>>>     mais là aussi, grande variété avec par exemple source="le nom - 
>>> la date"
>>>
>>>     Et puis il y a les tag fourre-tout, dont le sens exact est inconnu
>>>     ou dont le sens multiple rend sont utilisation problématique.
>>>     exemple survey="sortie de classe à tel date" ou d'autres dont on 
>>> ignore
>>>     si la date correspond à l'encodage dans osm (que le changeset donne
>>>     déjà) ou si c'est celle d'une visite sur le terrain ou d'une base de
>>>     donnée ou une date oü on a vérifié/corrigé la qualité style osmose
>>>           lastcheck
>>>           updated
>>>           check_exists:date
>>>     Si vous utilisez l'un d'entre eux ou connaissez outil qui l'utilise,
>>>     quel sens ?
>>>
>>>     Dernier problème : le format de la date. toutes les pages que j'ai
>>>     consultée parlent du format ISO 8601 basique YYYY-MM-DD, à tronquer
>>>     éventuellement lors que nécessaire genre 2017-09
>>>     En pratique c'est loin d'être le cas et on se retrouve avec
>>>     des valeurs 100117 qu'il nécessite de consulter l'historique de
>>>     l'objet pour faire la différence entre 10/01/2017 et 2010-01-17.
>>>     sans compter les mois en lettre ou les saisons, abrévié ou non.
>>>     bref, informatiquement quasi impossible à utiliser.
>>>
>>>     Evidement tout ces tags sont optionnel, mon propos n'est absolument
>>>     pas qu'on rajoute cela partout, surtout pas.
>>>     Mon propos n'est pas non plus de dire où cela doit être mis 
>>> (changeset
>>>     <> objet)
>>>     mon propos est plutôt de chercher, pour les projets qui en ont 
>>> besoin,
>>>     un moyen uniforme pour avoir l'info dans quelques tags commun plutôt
>>>     que d'en avoir une 20aine comme actuellement.
>>>     Cela permettrait des utilisations du genre :
>>>     - vérifier que les commerces n'ont pas changés après 2 ans.
>>>     - vérifier le fonctionnement des bornes après x mois.
>>>     - vérifier ce qu'est devenu un objet qui se trouverait dans
>>>     un import 2016 après que l'import 2017 ai validé tous les autres.
>>>
>>>     Qu'en pensez-vous ?
>>>     Si un besoin manque, n'hésitez pas à le décrire.



Plus d'informations sur la liste de diffusion Talk-fr