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