<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Le 08/07/2020 à 17:42, Florian LAINEZ a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CALZSDKJKa+Rz-wMzz_hBbmPAXNrFBtfiPWNoseA4v8ZFAge1jA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<p>Merci pour la prise de recul qui me paraît également
nécessaire Christian.<br>
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.</p>
<p>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".</p>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 ?</blockquote>
<div>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</div>
</div>
</blockquote>
<p><br>
</p>
<p>Un noeud entrance=* se situe sur le polygone du building=*... tu
oublies qu'OSM c'est de la donnée géo ?</p>
<p>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 ;)<br>
</p>
<p>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).<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CALZSDKJKa+Rz-wMzz_hBbmPAXNrFBtfiPWNoseA4v8ZFAge1jA@mail.gmail.com">
<div dir="ltr">
<div>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 <a
href="https://www.data.gouv.fr/fr/datasets/cinemas-issus-dopenstreetmap/"
moz-do-not-send="true">data.gouv</a></div>
<div><br>
</div>
</div>
</blockquote>
<p>Je sent qu'on va créer une nouvelle règle... "ne pas taguer pour
faciliter un export" ;)<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CALZSDKJKa+Rz-wMzz_hBbmPAXNrFBtfiPWNoseA4v8ZFAge1jA@mail.gmail.com">
<div dir="ltr">
<div><b>On a 3 solutions :</b></div>
<div><b>1. </b>on considère que l'adresse ne doit pas être
dupliquée : on la laisse donc sur un node flottant</div>
<div>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".</div>
<div>Quel node avec la bonne adresse associer au POI ? C'est
très difficile de retrouver cette info non explicite.</div>
<div><br>
</div>
<div><b>2. </b>on utilise <font face="monospace">contact:XXX</font>
pour dupliquer l'adresse sur le POI.</div>
<div>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.</div>
<div>C'est la solution que nous avons choisi à Montrouge pour
l'instant.</div>
<div><br>
</div>
<div><b>3. </b>on duplique l'adresse du point sur le POI en lui
rajoutant <span style="font-family:monospace">addr:role=contact</span></div>
<div>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.</div>
<div><br>
</div>
<div>Cette dernière option a ma préférence, qu'en pensez-vous ?</div>
</div>
</blockquote>
<p><br>
</p>
<p>J'ai regardé le fichier CNC, je ne vois pas d'adresse dedans.
Comment ont-elles été ajoutées dans OSM ?</p>
<p>A-t-on 100% des adresses correspondantes aux cinémas déjà dans
OSM ? (Et correctement mappées en tant que telles ?)</p>
<p>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) ?</p>
<p>Je ne comprends pas trop le processus...</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Christian Quest - OpenStreetMap France</pre>
</body>
</html>