Le 08/07/2020 à 17:42, Florian LAINEZ a écrit :
Merci pour la prise de recul qui me paraît également nécessaire Christian.
J'ai tout comme toi un problème avec l'info dupliquée qui pose
indubitablement problème. Dans un monde idéal, l'adresse
n'apparaîtrait qu'une fois et qu'une seule. Malheureusement le seul
moyen d'y parvenir me semble être de créer des relations, ce qui
complique vraiment le modèle et que l'on devrait donc éviter dans la
mesure du possible.
On est d'accord que pour l'usage "adresse", le point tel qu'il est
défini et utilisé aujourd'hui fait le taff. Ce que nous essayons
maintenant de trouver, c'est donc le moyen de gérer au mieux
l'utilisation "contact".
Pourquoi dupliquerai-t-on l'adresse sur chaque entrée/accès et pas
le type de POI (c'est une entrée... de cinéma, un sortie de
secours... de cinéma, etc) ? Où est la cohérence globale ?
Pourquoi répéter l'un mais pas l'autre ?
C'est un bon point. J'ai toujours été embêté par ces entrées qui ne
sont pas reliées au bâtiment et il me paraissait que l'adresse soit un
moyen élégant d'y parvenir mais tu as raison, je dois faire fausse
route en associant les deux problématiques. Tant pis pour les pompiers
qui ne seront pas guidés vers l'issue de secours
Un noeud entrance=* se situe sur le polygone du building=*... tu oublies
qu'OSM c'est de la donnée géo ?
L'abus de relation vient souvent du manque d'exploitable géographique
des données OSM. Les multipolygones qui entourent une commune (relations
par commodité pour segmenter les boundary et non par besoin sémantique),
font qu'on ne met plus de is_in=* partout depuis un bon bout de temps ;)
C'est quand on ne peut plus résoudre sans ambiguïté un lien entre deux
par la géographie qu'on passe à la relation où qu'on ajoute des tags
pour lever l'ambiguïté (par exemple les forward/backward sur les stop).
On en revient donc à l'usage "contact". Dans le use case que j'ai
exposé, il s'agit d'exporter tous les cinémas de France accompagnés de
leur adresse sur data.gouv
<https://www.data.gouv.fr/fr/datasets/cinemas-issus-dopenstreetmap/>
Je sent qu'on va créer une nouvelle règle... "ne pas taguer pour
faciliter un export" ;)
*On a 3 solutions :*
*1. *on considère que l'adresse ne doit pas être dupliquée : on la
laisse donc sur un node flottant
C'est plus avantageux pour la maintenance, c'est parfait pour l'usage
"adresse" mais c'est un cauchemar pour l'export et l'usage "contact".
Quel node avec la bonne adresse associer au POI ? C'est très difficile
de retrouver cette info non explicite.
*2. *on utilise contact:XXX pour dupliquer l'adresse sur le POI.
Pas top pour la maintenance, incompatible avec les outils d'édition
internationaux mais l'utilisation est très claire car les tags sont
différents pour les 2 usages. Parfait pour les 2 usages donc.
C'est la solution que nous avons choisi à Montrouge pour l'instant.
*3. *on duplique l'adresse du point sur le POI en lui rajoutant
addr:role=contact
Pas top pour la maintenance, compatible avec les outils d'édition
internationaux, bien adapté pour tous les lieux où il n'existe aucun
point adresse (ce qui représente la majorité des cas pour les
cinémas), mais il est nécessaire de faire une évolution pour
l'utilisation "adresse" afin que ce nouveau tag soit pris en compte.
Cette dernière option a ma préférence, qu'en pensez-vous ?
J'ai regardé le fichier CNC, je ne vois pas d'adresse dedans. Comment
ont-elles été ajoutées dans OSM ?
A-t-on 100% des adresses correspondantes aux cinémas déjà dans OSM ? (Et
correctement mappées en tant que telles ?)
J'ai regardé celui près de chez moi, aucune info d'adresse dessus,
quelle adresse aura-t-il dans l'export ? La plus proche qu'on trouve
(donc un simple géocodage inverse) ?
Je ne comprends pas trop le processus...
--
Christian Quest - OpenStreetMap France
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
