<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 7 janv. 2021 à 22:34, <<a href="mailto:osm.sanspourriel@spamgourmet.com">osm.sanspourriel@spamgourmet.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Philippe, il me semble que Bernard voulait uniquement dire "faire<br>
disparaître" *shelter=yes/no* des platform et que les objets poubelle<br>
devraient être ajoutés à la relation stop area.<br></blockquote><div><br></div><div>J'avais parfaitement compris et j'ai été clair, je parlais bien de ça, et à mon avis ce n'est PAS à faire car cela ne fait pas partie des rôles pour lesquels les arrêts (les objets "stop" uniquement) sont membres de cette relation.</div><div>Logiquement il n'ont rien à faire dans la relation car ils ne sont PAS localisés dans *toute* la relation (où il peut encore manquer des membres, dont les "stop_position",), pas plus que et les différentes lignes ("route" ou "route_master") qui s'y connectent (même si ces "route_*" ne sont pas membres directement).</div><div><br></div><div>Et dans le cadre des relations "route/route_master" justement, elles référencent les lignes et arrêts, pas directement les relations "stop_area" qui font les interconnexions d'un réseau: ce sont aux objets "stop" membres des "route" qu'on s'attend à trouver les infos liées sur les abris ou équipements... qui du coup vont disparaitre des schémas de lignes (plus d'indication par exemple sur l'accessibilité d'une station, ou un point d'information/guichet voyageur, ou un abri: un outil qui voudrait les afficher sous forme de notes ou d'icones sera perdu, il lui faudra rechercher pour chaque arrêt s'il fait partie d'une relation "stop_area", et s'il le fait il risque de trouver des infos fausses sur cette arrêt qui n'a pas cet équipement.</div><div><br></div><div>Rien que les poubelles, on ne les met sur un arrêt que pour éviter un second noeud proche alors que ces poubelles sont dans (ou collées à) un abri (souvent en fait les poubelles sont plutôt à côté pas loin on aurait pu les mettre sur un noeud séparé. De même une "stop_area" a vocation a contenir un membre surfacique pour par exemple un batiment (comme une gare), un parking, des quais, des couloirs (ou tapis roulants, escalators, ascenceurs...) d'interconnexion. Chaque arrêt individuel peut avoir d'autres éléments (télésurveillance par exemple, barrières de contrôle d'accès, bornes d'achats de titres) qu'on ne trouve pas dans tous les autres membres de la relation "stop_area".</div><div><br></div><div>Il faut s'en tenir au "rôle" donné à chaque membre inclus dans la relation membre_area: une poubelle ou un abri n'est pas un "stop" et n'a pas ce rôle et ne fait pas partie des autres membres "stop position". Et s'il y a un membre pour la gare ou un parking (tagués comme des surfaces normales en "way fermé" ou relation "multipolygon"), on ne saura plus localiser ces petits équipements qui ne sont que là où l'indique indivisuellement chaque "stop".</div><div><br></div><div>C'est une question de logique et cela bloquera encore plus les modifications des "stop_area" s'il faut aller les inspecter un par un pour voir s'il n'y a pas "trop" de membres dedans auxquels ces attributs ne s'appliquent **pas**.</div><div><br></div><div><br></div></div></div>