[OSM-talk-fr] les dates de terrain, de test fonctionnel, d'import, de source
marc marc
marc_marc_irc at hotmail.com
Ven 29 Sep 15:32:28 UTC 2017
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.
Plus d'informations sur la liste de diffusion Talk-fr