> > J'ai regardé le fichier CNC, je ne vois pas d'adresse dedans. Comment > ont-elles été ajoutées dans OSM ? > A la force de l'huile de coude des contributeurs en se basant sur diverses sources à notre dispo.
Les données sont extraites d'OSM tous les jours via https://geodatamine.fr/dump/ puis publiées sur https://www.data.gouv.fr/fr/datasets/cinemas-issus-dopenstreetmap/ Tant que nous discutons du bon tag à utiliser dans cette discussion, les adresses ne sont pas encore incluses dans l'export. Adrien peut te détailler encore plus le process d'export si besoin. C'est lui le "faiseur" ;) A-t-on 100% des adresses correspondantes aux cinémas déjà dans OSM ? (Et > correctement mappées en tant que telles ?) > Non, pas du tout mais c'est bien l'objectif. > 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) ? > A ce stade nous n'avons réalisé que des opérations manuelles. > Je sent qu'on va créer une nouvelle règle... "ne pas taguer pour faciliter > un export" ;) > Je comprends la logique mais l'usage "contact" vaut bien autant que l'usage "adresse" ;) Bien que l'on devrait faire un max d'effort pour faciliter la maintenance, la donnée ne devrait pas non plus être créée pour ne pas être utilisable en aval, au risque de rendre OSM inutile. Le principe d'une base de données est bien de pouvoir faire des requêtes automatiques pour extraire des données en masse. Trouvons ensemble le meilleur moyen d'y parvenir sans tout casser :P Le jeu. 9 juil. 2020 à 08:57, Christian Quest <cqu...@openstreetmap.fr> a écrit : > 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 > -- *Florian Lainez* @overflorian <http://twitter.com/overflorian>
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
