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

[Violaine Doutreleau]

Hello,

@Marc, justement je pointais l'attention sur 'il ne faut pas mixer', on 
est donc daccord J


Sinon je te rejoins, on pourrait séparer les éléments visibles 
basiquement (sans recherche approfondie) et les inclure par défaut dans 
le survey:date. Pour les éléments plus spécifiques/+ approfondis,  
ajouter un :date à la fin de la clé. (type capacity:bed, le nombre de 
staffs etc, ds le cadre des infrastructures de santés, informations 
qu'un contributeur de lamba de passage dans la région ne va pas 
forcément aller chercher). Je te rejoins aussi sur la difficulté 
d'interprétation du check_date, qui pourrait se recouper avec le 
source:date; ou /clé/:date, ou on ne sait pas ce qui a été vérifié, comment.


@Christian, merci!

A +

Violaine

Le 12/09/2017 à 14:01, marc marc 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 

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

[marc marc]

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é 

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

[marc marc]

@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 "_" 

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

[Christian Quest]

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 -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 
> 

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

[Violaine Doutreleau]

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 -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


--
*Violaine Doutreleau*
Coordinatrice Missing Maps
CartONG 
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

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

[marc marc]

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 -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