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

[marc marc]

Bonjour,

N'ayant reçu aucun objection, j'ai harmonisé  l'échelle de la France
source_date et date:source en faveur du tag majoritaire source:date
date:survey en faveur du tag majoritaire survey:date

Pour bien faire, il reste à faire :
- faire la même chose ailleurs (je lancerai la discussion sous peu de 
l'autre côté de la frontière, voir au niveau mondial si motivé)
- relancer la proposition sur les tests fonctionnel operational_status
- essayer de raffiner ceux dont le sens exact est inconnu (lastcheck, 
check_date)

Le 29. 09. 17 à 17:32, Marc M. a écrit :
> 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.
>