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