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. 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/> *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 ? Le mer. 8 juil. 2020 à 16:58, Éric Gillet <e+talkfr2...@linuxw.info> a écrit : > Je suis 100% d'accord et j'applique ce qu'indique Christian. > > Le 08/07/2020 à 16:17, Christian Quest a écrit : > > En général ce qui me gêne c'est : > > - la duplication de l'information, > > - et pour dédupliquer le besoin de vérifier des tags en plus pour se dire > que non, ce n'est pas ce que je cherche (ça complique beaucoup la > réutilisation des données, on a déjà eu le cas avec les "disused") > > > 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 > ? > > > On prends un peu de recul ? A quoi servent le plus souvent les adresses ? > > 1) à retrouver la position d'un lieu quand on n'a pas d'autre information > pour s'y rendre (adresse géographique) avec une description hiérarchique > (commune > voie > numéro > complément comme le bâtiment ou un numéro > d'entrée, d'escalier) > > 2) à faire des envois à un destinataire (adresse postale), là il n'y a pas > forcément concordance géographique (cas des CEDEX, BP et autre, mais aussi > des secrétariats qui ne sont pas sur place). > > De mon point de vue, contact:xxx répond à ce besoin d'adresse postale, çàd > quelle adresse je met pour un contact par courrier. Elle ne devrait jamais > être utilisée pour du routage pour cette raison. > > > L'adresse géo, elle, servira à déterminer une position pour un calcul > d'itinéraire si on n'a pas mieux, car si je cherche "Ciné Montrouge", je > n'ai pas besoin de son adresse... la position du POI suffit à calculer > l'itinéraire, qui d'ailleurs quand on fournit juste une adresse va chercher > la position géographique correspondant pour faire ensuite son routage. > > Si je veux aller au 88 rue Racine (sans savoir que c'est là où il y a le > ciné, l'espace Colucci, etc), un seul noeud suffit pour ça. > > Donc dans les exemples que tu donnes: > > > Voici donc l'exemple de la mairie de Montrouge, constitué d'un > bâtiment avec 3 accès : > - le bâtiment https://www.openstreetmap.org/way/83237614 > addr:role=contact > - l'entrée principale https://www.openstreetmap.org/node/2232200912 > addr:role=entrance;visitors > - l'entrée secondaire https://www.openstreetmap.org/node/2443190668 > addr:role=entrance;delivery > - l'entrée reservée au personnel > https://www.openstreetmap.org/node/6245192824 > addr:role=staff > > L'adresse pourrait être simplement sur le bâtiment, ensuite chaque > entrée/accès avec un noeud entrance=* et décrivant les règles d'accès. > > Pas besoin de dupliquer addr:xxx partout dans un tel cas. > > > Pour un exemple plus classique et simple d'un cinéma, on aurait : > - le bâtiment https://www.openstreetmap.org/way/83233476 > addr:role=contact > - l'entrée principale https://www.openstreetmap.org/node/5914047022 > addr:role=entrance > - la sortie de secours https://www.openstreetmap.org/node/7694884485 > addr:role=emergency > > Il me semble que ce modèle est solide et remplacerait avantagement > addr:contact > Assigner des *usages* aux adressses : Christian n'est pas l'évolution > dont tu rêves depuis des lustres ? > > Sur ce cas, l'Espace Colucci me semble être le site entier, la parcelle, > car on y trouve aussi un théâtre d'extérieur et le cinéma fait partie de > cet espace (je suis allé voir sur leur site web). Les 3 adresses serait > bien à leur place en limite de la parcelle entière, le 88 au début du > footway qui mène à l'entrée, le 129 sûrement plutôt à la grille, le 131 à > l'escalier qui donne sur la rue. > > > On a, je pense, trop tendance à ramener tout aux bâtiments, des tags, des > noeuds d'adresse, etc > > Sur le centre sportif juste à côté, le sport_centre est sur le site > entier... les adresses en limite de parcelle (no comment sur les deux > name=Gymnase). > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > -- *Florian Lainez* @overflorian <http://twitter.com/overflorian>
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
