Le 30/08/2020 à 10:18, Yves P. a écrit :
Autre champ à exploité éventuellement : *c_xy_precis*
Il est documenté : "/Il s’agit du niveau de précision de la
localisation selon la méthode utilisée pour poser le point XY à cet
endroit./"
C'est une valeur renvoyée par le géocodeur (addok ?, avec quelle base
de données ?, géocodage réalisé quand ?)
Il y en a seulement 1074 sur les 16753 :/
Les valeurs vont de 0.999914 à 1.0000.
A vérifier lors de l'intégration si la position effective du DAE est
meilleure (il n'est probablement jamais localisé sur le point adresse)
Si c'est un champ de la base GeoDAE, celle-ci n'est en principe pas
géocodée d'après l'échange téléphonique que nous avons eu Adrien et moi
avec les gestionnaires il y a une dizaine de jours.
C'est dommage d'ailleurs car cela permet de détecter des positions
anormalement éloignées du point d'adresse quand on le trouve.
On a d'autres soucis avec *reception_desk* et *security_desk*
Je suis donc partisan de ne pas les intégrer. Ce n'est pas le premier
cas du genre signalé sur la liste.
Je les efface consciencieusement avec *operator:ref:FR:SIREN* :P
Source non fiable sur ces champs... donc évitons de recopier des
erreurs. Pour le SIREN, aucun idée concernant sa fiabilité, le mieux est
de le retrouver lui aussi par l'id GéoDAE si on en a besoin.
De plus ça ne me semble pas apporter grand chose (parce que c'est une
donnée dans GéoDAE et que je ne vois pas trop à quoi ça sert :
Peut-être pour les opérateurs ou logiciels du Centre de Traitement des
Appels (CTA) ?
Pour prévenir ou rappeler un interlocuteur de "confiance" ??
Mais sur le terrain ce qui est important c'est :
* le lieu "Salle des fête",
* la description de sa position "sous le auvent à gauche de l'entrée
principale"
* et une bonne photo de situation
Ces informations sont aussi importantes pour le cartographe qui
souhaite positionner précisément le DAE ;)
Ou pour quelqu'un qui aimerait vérifier la qualité des données.
Et surtout pour quelqu'un qui a besoin d'un DAE ;)
Source : ne faut-il pas millésimer ? Version Adrien : je suggère de
millésimer la source comme pour les autres données,
"Volontiers" comme disent les Helvètes :)
Il y a une date de mise à jour sur la page de téléchargement
<https://www.atlasante.fr/geonetwork/srv/fre/catalog.search;jsessionid=E7AB0C5B1D68019928A7E1C5E90A8251#/metadata/f9bc1743-deae-446d-b9fa-bab68b2aaee9>,
mais elle ne semble pas être disponible dans le fichier CSV.
A défaut, je suggère de mettre la date du téléchargement faite par
osmose ?
+1 !
Position : foireuse (proche mais à l'extérieur du bâti malgré
indoor=yes). On met un fixme=geometry ?
Il y a de tout dans ce que j'ai pu intégrer.
Je suggère plutôt de rappeler de façon claire et ludique ce que c'est
que de l'intégration :)
Il "faut" vérifier, recouper les informations, re-vérifier :)
Adrien, désolé pour la forme impérative ;)
Quand j'ai de gros doutes, je met un fixme du genre "vérifier la
position"…
Quand j'ai de trop gros doutes, je n'intègre pas. Il manque un tag clair
et universel pour dire que la position d'un objet dans OSM est
approximative voire juste estimée et pas fiable du tout.
Avec un tel tag, on éviterai de rendre visible sur le rendu un DAE qui
n'est pas forcément là, voire même à proximité, bref, ça éviterai
d'induire en erreur, avec les conséquences que ça peut avoir dans ce cas
bien précis.
--
Christian Quest - OpenStreetMap France
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
