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

[Violaine Doutreleau]

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.
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
*Violaine Doutreleau*
Coordinatrice Missing Maps
CartONG <http://www.cartong.org>
mobile : 06.95.02.42.44
skype : doutreleau.violaine


_P Help save paper - do you need to print this email?_
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20170911/0db72dd0/attachment.htm>