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

Lun 11 Sep 19:21:14 UTC 2017

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 <v_doutreleau at cartong.org>
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.
> _______________________________________________
> Talk-fr mailing listTalk-fr at openstreetmap.orghttps://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?*
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>

-- 
Christian Quest - OpenStreetMap France
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20170911/4eab62eb/attachment.htm>