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_doutrel...@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@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@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > -- Christian Quest - OpenStreetMap France
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr