[OSM-talk-fr] Sensibiliser à OpenStreetMap - Dépliant OSM France

[Julien Lepiller]

Le 2019-02-07 11:21, Rpnpif a écrit :
> Bonjour,
> 
> Le  6 février 2019, Eric a écrit :
> 
>> Bonjour,
>> 
>> J'ai eu à en faire un rapidement pour une présentation récente, si ça 
>> peut
>> aider...
>> http://www.blueb.fr/osm/PresOSM.pdf   (ou .docx)
>> http://www.blueb.fr/osm/SlidesOSM.pdf    (ou pptx)
> 
> Merci pour ce travail très intéressant.
> 
> Juste quelques petites remarques :
> 
> Je traduirais « field papers » par « papier, crayon » si c'est bien le
> sens.

Si on en est là, moi je traduis « tag » par « attribut » et « way »
par « chemin » ;)

> 
> « Pas de données nominatives », le tag operator sur les commerces ou
> services est parfois ou souvent complété par une donnée nominative.
> C'est interdit ? De même le nom d'une zone est nominatif par
> définition ;). À moins que nominatives veuillent dire données
> personnelles d'un individu, donc données « personnelles » (répétition).
> 
> « Pas de données ponctuelles dans le temps » : la plupart des données
> évoluent dans le temps. Des routes se modifient et se créent, des noms
> changent, des routes ou zones en travaux sont reportées (à condition de
> suivre leur finalisation), des arbres disparaissent, etc. Donc c'est
> une affirmation à nuancer.
> C'est une question générale qui ne me semble pas faire consensus. Je
> pense que l'on peut reporter une donnée temporaire si on est capable
> soi-même ou avec l'aide de contributeur plus proche, et à terme, de la
> faire évoluer jusqu'à un état soi-disant plus stable. Cela sous-entend
> de suivre en quasi temps réel. C'est très utile pour le calcul
> d'itinéraires.

À mon avis il faut différencier deux cas : la donnée est bonne en 
général
mais il y a actuellement un changement d'état temporaire (par exemple 
des
travaux bloquent une route pour quelques jours, mais ensuite il n'est
pas prévu de changer la rue) et la donnée est incorrecte mais on est
en transition (par exemple, un local commercial en travaux avant 
l'ouverture
d'un nouveau magasin).

Je vous propose deux exemple : le premier, c'est une route bloquée pour
cause de travaux pendant quelques jours, sans que le tracé ou le 
propriétés
de la route ne doivent changer. Le deuxième, c'est un local commercial
qui abritait un magasin de vêtements et qui change de propriétaire, pour
devenir un magasin d'instruments de musique. Le local est en travaux 
pour
refaire la décoration.

Dans le premier cas, cela peut demander de la réactivité pour rétablir
l'ancienne donnée et il n'est pas forcément très utile de changer la
donnée de manière temporaire.

Dans le deuxième cas, ça n'a pas de sens de laisser la donnée même
si l'état actuel est temporaire : l'ancien magasin ne reviendra pas,
inutile donc de le laisser. Si on ne peut pas surveiller l'arrivée
du nouveau magasin, on peut au moins laisser une note, mais je ne crois
pas qu'il soit nécessaire de pouvoir être réactif dans ce cas.

Donc, on peut mettre à jour dans les cas de transition (l'ancienne 
donnée
est fausse et le restera), mais pas les cas de modifications temporaires
(l'ancienne donnée n'est actuellement pas valide, mais le sera de 
nouveau
un peu plus tard), sauf si on peut s'engager à maintenir la donnée en
question ou que le temporaire est particulièrement long.

Il faut penser aussi aux utilisations qui ne mettent à jour que rarement
leur carte (osmand, ...) et qui risquent de voir ces changements pendant
plus de temps que nécessaire. Mais on ne cartographie pas pour le
rendu, n'est-ce pas ?

Finalement, pour dire tout ça en une phrase, c'est pas facile ;)

> 
> Je m'inspirerai de ce travail très utile.