[OSM-talk-fr] Arrêt de bus, comment tagger les équipements?

Philippe Verdy verdyp at gmail.com
Jeu 7 Jan 21:11:27 UTC 2021


Une stop area peut être très vaste, son but est lié au schéma de transport
pour les interactions; cela n'a rien à voir avec les abris, bancs ou
poubelles qui sont autour : mettre ces attributs qui conernent un objet
individuel et pas automatiquement les autres dans la relation "stop_area"
n'a pas grand sens.
La relation stop_area a des membres bien précis pour indiquer leur rôle. La
facilité qu'on a de pouvoir ajouter "shelter/bench/bin=yes/no" sur un autre
objet est une simplication de cet objet qui évite juste de créer un autre
objet au **même endroit** cet endroit n'est **pas** la stop_area" entière
Bref je pense qu'on ne doit pas déplacer les attributs des membres de la
relation "stop_area" (qui ne sont membres que pour leur rôle particulier
dans le schéma de transport et les interconnexion, indépendamment de leur
équipement annexe qui ne participe pas à ce rôle) vers cette relation qui
n'est pas un "multipolygon" (ou une frontière "boundary": variante qui
existe juste parce qu'elle a quelques rôles supplémentaires mais qui là
aussi décrit la géométrie d'une surface entière).
Un tel déplacement n'est pas prévu et ne fait que compliquer: une stop_area
peut très bien avoir un banc dans un des arrêts et pas un autre, une
poubelle dans un et pas un autre, la stop_area peut aussi avoir des neuds
d'emplacements d'arrêt sur la voie où ces équipements ne sont **pas**
présents (sur la voir même, certainement pas à ces endroits).
Ces petits équiepements doivent rester au niveau le plus géolocalisé
localement, la "stop_area" étant trop grande.
Il vaut mieux s'en tenir au schéma de transport tel qu'il est défini (par
ses rôles) et éviter une telle extension sémantique qui n'a pas grand sens.


Le jeu. 7 janv. 2021 à 18:47, blef <bernard.lefrancois at free.fr> a écrit :

> Bonjour
>
> En cartographiant le réseau de bus de ma ville, j'avais pris la décision
> de représenter les arrêts de bus, pour la partie *platform*, par un nœud
> avec en plus de l'attribut *public_transport=platform* les différents
> attributs décrivant l'équipement de l'arrêt: *shelter=yes/no*,
> *bench=yes/no*, *bin=yes/no* etc.
> J'avais aussi créé systématiquement un relation *stop_area* pour chaque
> arrêt.
>
> Au fil du temps, d'autres contributeurs ont ajouté séparément certains de
> ces équipements, par exemple sur un nœud (ou way) *amenity=shelter* +
> *shelter_type=public_transport* ou *amenity=waste_baske**t*.
> D'après le wiki, et pour respecter le mantra *One feature, One OSM
> element*,  les attributs *shelter=yes/no*, *bench=yes/no*, *bin=yes/no*
> devraient être supprimés sur le nœud *public_transport=platform*.
> De plus les nouveaux objets devraient être ajoutés comme membres de la
> relation *stop_area*.
>
> On gagne certes en précision et détail, mais je doute que les principales
> applications orientées transport soient alors capable d'indiquer de façon
> complète l'équipement de l'arrêt.
> Même en allant regarder dans la relation *stop_area*, il faudrait
> associer correctement chaque équipement avec la *platform* concernée, pas
> facile à faire et ça m'étonnerait que ça se fasse.
>
> J'aimerais connaitre votre avis sur la question pour décider de la
> meilleure méthode à appliquer.
> Merci.
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20210107/c40bae23/attachment-0001.htm>


Plus d'informations sur la liste de diffusion Talk-fr