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

[Florian LAINEZ]

Hello,
N'ayant pas grand chose à ajouter, je n'ai pour l'instant pas pris part à
la discussion.

Il me semble en effet que la cohabitation entre tags sur l'arrêt ou objets
à proximité va perdurer.
Côté exploitants (autorités organisatrices des transports, transporteurs
...) qui sont les clients de l'entreprise Jungle Bus, il est évident que
seuls les tags présents sur les arrêts eux-mêmes sont pris en compte. C'est
la raison pour laquelle c'est la modélisation favorisée lorsque nous menons
des projets de cartographie.

mettre tout dans un stop_area conduit à avoir une relation avec des
> milliers de membres pour la gare du nord à Paris, sans que la plus-value
> saute aux yeux (les relations ne sont pas des collections).

Je suis un peu responsable de cette situation en ayant pris la décision de
créer une relation par gare en Ile-de-France. Je suis conscient que ce
n'est pas l'idéal et que cela amène de la complexification difficile à
gérer et à maintenir.
Néanmoins la SNCF et plusieurs entreprises sous-traitantes utilisent dans
les faits ces relations pour identifier les objets relevant de leur
périmètre d'action. Je vous demanderais donc de ne pas les supprimer.

Les relations... sont souvent de fausses solutions ;)
>
Je confirme. FBI : Fausse Bonne Idée.

Le ven. 8 janv. 2021 à 15:08, blef <bernard.lefrancois at free.fr> a écrit :

> Bonjour,
>
> Merci pour vos avis.
>
> Si je résume:
>
>
>    - Inclure les shelter, bench, bin séparés dans la relation *stop_area*?
>    Personne n'y semble favorable, moi non plus.
>    Dommage que le wiki/FR:Tag:public_transport=platform
>    <https://wiki.openstreetmap.org/wiki/FR:Tag:public%20transport=platform?uselang=fr>
>    ou wiki/FR:Key:public_transport
>    <https://wiki.openstreetmap.org/wiki/FR:Key:public_transport>
>    préconise de le faire: *Le lieu d'attente est normalement associé aux
>    autres éléments de l'arrêt (**stop_position**,* *bancs**,* *abris**,
>    ...) à l'aide d'une relation de type* *public_transport=**stop_area*
>
>
>    - Garder les deux indications: shelter=yes sur l'arrêt (platform) et
>    amenity=shelter sur un node ou way séparé?
>    Ça ne semble choquer personne, même si je n'ai pas l'impression qu'il
>    y ait consensus sur le fait que ce soit un doublon, ou pas.
>    Le wiki (encore lui) recommande:
> *shelter=yes indique si un abri est présent (s'il n'est pas déjà tagué
>    avec amenity=shelter) *L'idée d'utiliser la valeur separate me plait
>    bien. Ça donnerait, si j'ai bien compris: shelter=separate au lieu de
>    shelter=yes sur l'arrêt (platform), l'objet lui même étant représenté à son
>    emplacement avec amenity=shelter.
>    Dommage encore que cette solution ne soit pas documentée, et sans
>    doute pas prise en compte par les appli genre Osmand et autres.
>
>    Autre remarque, même si on est sensé ne pas s'en préoccuper, sur le
>    rendu standard la présence d'un amenity=shelter près d'un arrêt masque ce
>    dernier à certains facteur de zoom.
>
> Donc, pour l'instant, je ne touche à rien. Personnellement, je suis
> attaché aux attributs shelter/bench=yes/no sur l'arrêt (platform), parce
> que c'est reconnu par les applis que je connais, et parce que ça me permet
> une certaine homogénéité dans le tagging de tous les arrêts du réseau.
>
> Si vous avez d'autres idées...
>
>
> Le 07/01/2021 à 18:46, blef 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 listTalk-fr at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 

*Florian Lainez*
@overflorian <http://twitter.com/overflorian>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20210108/195950e2/attachment.htm>