Arrêt de bus, comment tagger les équipements?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Arrêt de bus, comment tagger les équipements?

blef

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_basket.
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

France mailing list

Le 07-01-2021 18:46, blef a écrit :

...
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_basket.



amenity=shelter/waste_basket alors qu'il y a déjà shelter=yes ou bin=yes sur l'arrêt, c'est un doublon ! Qui n'a donc aucun intérêt.

Mais en général, je contacte d'abord l'utilisateur pour lui exposer ce que j'ai l'intention de faire afin de garder une cohérence / maintenabilité. Ceci afin d'éviter une guerre de modifs.

Si c'est un fanatique des poubelles sur les nœuds, je laisse tomber, il y a mieux à faire pour améliorer la qualité OSM.  :-)




_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

Bibi
C'est vrai inutile de le traiter de tête de nœud ^^.

Le 07/01/2021 à 21:22, Georges Dutreix via Talk-fr -
[hidden email] a écrit :
>
> Si c'est un fanatique des poubelles sur les nœuds, je laisse tomber,
> il y a mieux à faire pour améliorer la qualité OSM.  :-)
>


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

Philippe Verdy
In reply to this post by blef
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 <[hidden email]> 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_basket.
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

France mailing list
In reply to this post by Bibi

C'est de la sagesse. Le contributeur qui veut absolument ajouter son nœud dans l'arrêt, il ne faut pas tenter d'intervenir.

Le 07-01-2021 21:58, [hidden email] a écrit :

C'est vrai inutile de le traiter de tête de nœud ^^.

Le 07/01/2021 à 21:22, Georges Dutreix via Talk-fr -
[hidden email] a écrit :

Si c'est un fanatique des poubelles sur les nœuds, je laisse tomber,
il y a mieux à faire pour améliorer la qualité OSM.  :-)



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

Bibi
In reply to this post by Philippe Verdy

Philippe, il me semble que Bernard voulait uniquement dire "faire
disparaître" *shelter=yes/no* des platform et que les objets poubelle
devraient être ajoutés à la relation stop area.
Logiquement il a raison.
Encore que une poubelle est elle intrinsèquement partie de la relation ?
Non, vous pouvez déposer un papier sans valider un ticket ;-).
Perd-t-on de le l'information ? Nom, par proximité géographique on peut
retrouver les poubelles.

Je ne vois pas trop l'intérêt de positionner les poubelles sauf que :
- ça peut permettre à un aveugle de l'utiliser (mais s'il a un papier à
jeter il le fera plus efficacement à la maison). Au fait bonne année
Sébastien, tu peux nous dire si ça te semble utile.
- ça peut permettre d'ajouter une référence afin de faciliter la
déclaration de dégradations à la maire par exemple.

Ceci dit pour moi savoir qu'il y a une poubelle à un arrêt c'est du
luxe. Si je dois aller prendre le bus je vais peut-être ne pas choisir
l'arrêt le plus proche pour avoir un abri, par contre ne pas descendre à
un arrêt parce qu'il n'y pas de poubelle... Là éventuellement c'est la
distance de la poubelle la plus proche qui m'intéresse.

Bernard, tu peux dire que le poubelle n'était pas à décrire car déjà
dans shelter=yes. Et s'il le contributeur incite, tu lui demande de
mettre à jour la plateforme et supprimant *shelter=yes*.

Oui il est probable que quelqu'un ne voyant pas la poubelle l'ajoutera.

Il me semble qu'on a plus intéressant à faire que de se prendre le chou
avec.

Donc un message et expliquant pourquoi il ne faut pas faire comme il le
fait doit suffire : tu lui donnes les 2 possibilités.

Jean-Yvon



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

Philippe Verdy


Le jeu. 7 janv. 2021 à 22:34, <[hidden email]> a écrit :

Philippe, il me semble que Bernard voulait uniquement dire "faire
disparaître" *shelter=yes/no* des platform et que les objets poubelle
devraient être ajoutés à la relation stop area.

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.
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).

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.

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".

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".

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**.



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: SPAM, Re: Arrêt de bus, comment tagger les équipements?

Arnaud Champollion
In reply to this post by Bibi
Le 07/01/2021 à 22:33, [hidden email] a écrit :

> Je ne vois pas trop l'intérêt de positionner les poubelles sauf que :
> - ça peut permettre à un aveugle de l'utiliser (mais s'il a un papier à
> jeter il le fera plus efficacement à la maison).

Moi je m'en sers en micro-mapping pour faire de l'orientation avec de
jeunes élèves.

Comme on travaille sur des zones peu étendues (souvent moins de 300
mètres) on utilise beaucoup de détails pour se repérer.

Et tout est bon à prendre : poubelles, arbres, souches, blocs de béton,
lampadaires ... du moment qu'il y a un attribut OSM pour ça et que
l'objet existe sur le terrain.

Arnaud


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

cquest
In reply to this post by Bibi
Les relations... sont souvent de fausses solutions ;)

bench=yes ou bin=yes, indique qu'il y a un banc ou une poubelle à cet
arrêt, mais ça n'indique pas l'emplacement exact de ces objets, juste,
qu'il y a ce type d'équipements, c'est un premier niveau de description.

une géométrie avec amenity=bench ou amenity=waste_wasket indique où se
trouvent ces équipements, et je ne pense pas que ça fasse doublon avec
les tags précédents, c'est un second niveau de description

Mettre ça dans une relation... bof bof bof... surtout une stop_area avec
plein de platform, etc...

Si on veut savoir si il y a une poubelle ou un banc à un arrêt, on
devrait le faire sur bench=yes et bin=yes et c'est bien plus simple que
de se farcir des relations.

Si on veut savoir quels sont les bancs/poubelles à proximité d'un arrêt,
on le fait par la géométrie

Savoir que tel banc fait partie de l'arrêt est délicat, sauf pour un
abribus ou il n'y a pas d'ambiguité. Sur un arrêt "poteau" il y a
parfois un banc à proximité, je ne sais pas si c'est la RATP ou la Ville
qui l'a installé, etc, etc...


Le 07/01/2021 à 22:33, [hidden email] a écrit :

>
> Philippe, il me semble que Bernard voulait uniquement dire "faire
> disparaître" *shelter=yes/no* des platform et que les objets poubelle
> devraient être ajoutés à la relation stop area.
> Logiquement il a raison.
> Encore que une poubelle est elle intrinsèquement partie de la relation ?
> Non, vous pouvez déposer un papier sans valider un ticket ;-).
> Perd-t-on de le l'information ? Nom, par proximité géographique on peut
> retrouver les poubelles.
>
> Je ne vois pas trop l'intérêt de positionner les poubelles sauf que :
> - ça peut permettre à un aveugle de l'utiliser (mais s'il a un papier à
> jeter il le fera plus efficacement à la maison). Au fait bonne année
> Sébastien, tu peux nous dire si ça te semble utile.
> - ça peut permettre d'ajouter une référence afin de faciliter la
> déclaration de dégradations à la maire par exemple.
>
> Ceci dit pour moi savoir qu'il y a une poubelle à un arrêt c'est du
> luxe. Si je dois aller prendre le bus je vais peut-être ne pas choisir
> l'arrêt le plus proche pour avoir un abri, par contre ne pas descendre à
> un arrêt parce qu'il n'y pas de poubelle... Là éventuellement c'est la
> distance de la poubelle la plus proche qui m'intéresse.
>
> Bernard, tu peux dire que le poubelle n'était pas à décrire car déjà
> dans shelter=yes. Et s'il le contributeur incite, tu lui demande de
> mettre à jour la plateforme et supprimant *shelter=yes*.
>
> Oui il est probable que quelqu'un ne voyant pas la poubelle l'ajoutera.
>
> Il me semble qu'on a plus intéressant à faire que de se prendre le chou
> avec.
>
> Donc un message et expliquant pourquoi il ne faut pas faire comme il le
> fait doit suffire : tu lui donnes les 2 possibilités.
>
> Jean-Yvon
>
>
>
> _______________________________________________
> Talk-fr mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-fr
>
--
Christian Quest - OpenStreetMap France


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Christian Quest - cquest@openstreetmap.fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

Marc_marc
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).
surtout que la limite est sans fin : cet arrêt à un vendeur de café,
un magasin de journaux, un parking, une entreprise de bureau partagé
à l'étage, ...

bench=yes <> amenity=bench ne représente pour moi pas la même chose :
le premier est une caractéristique de l’arrêt (cet arrêt à un banc), le
deuxième est l'objet "banc"

si on veux éviter les bouclons de stats entre "je compte une première
fois les arrêts dotés d'un banc" et "les bancs", certains utilisent
bench=separate (sur le modèle de sidewalk=separate), cela indique
que l'arrêt à un banc et qu'il a été renseigné lui aussi par un objet
cela a aussi l'avantage de pouvoir monter en qualité (celui qui veux
ajouter des bancs n'a qu'à prendre les bench=yes et sait renseigner
ceux qui sont traité)
idem pour bin=separate shelter=separate

dans tous les cas, je n'effacerais ni bench=yes ni amenity=bench,
cela n'apporte rien d'autres que de faire du yoyo entre
ajout/suppression puisque les 2 sont juste



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

Éric Gillet-3
In reply to this post by cquest
Le 08/01/2021 à 09:46, Christian Quest a écrit :

> Les relations... sont souvent de fausses solutions ;)
>
> bench=yes ou bin=yes, indique qu'il y a un banc ou une poubelle à cet
> arrêt, mais ça n'indique pas l'emplacement exact de ces objets, juste,
> qu'il y a ce type d'équipements, c'est un premier niveau de description.
>
> une géométrie avec amenity=bench ou amenity=waste_wasket indique où se
> trouvent ces équipements, et je ne pense pas que ça fasse doublon avec
> les tags précédents, c'est un second niveau de description
>
> Mettre ça dans une relation... bof bof bof... surtout une stop_area
> avec plein de platform, etc...
>
> Si on veut savoir si il y a une poubelle ou un banc à un arrêt, on
> devrait le faire sur bench=yes et bin=yes et c'est bien plus simple
> que de se farcir des relations.
>
> Si on veut savoir quels sont les bancs/poubelles à proximité d'un
> arrêt, on le fait par la géométrie
>
> Savoir que tel banc fait partie de l'arrêt est délicat, sauf pour un
> abribus ou il n'y a pas d'ambiguité. Sur un arrêt "poteau" il y a
> parfois un banc à proximité, je ne sais pas si c'est la RATP ou la
> Ville qui l'a installé, etc, etc...


Bon j'ai pas besoin d'écrire une réponse, ça correspond exactement à mon
point de vue, merci Christian :)


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

leni-2
In reply to this post by Marc_marc

Le 08/01/2021 à 10:49, Marc_marc a écrit :
> 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).
> surtout que la limite est sans fin : cet arrêt à un vendeur de café,
> un magasin de journaux, un parking, une entreprise de bureau partagé
> à l'étage, ...
Pareil, je ne vois pas l'utilité

> bench=yes <> amenity=bench ne représente pour moi pas la même chose :
> le premier est une caractéristique de l’arrêt (cet arrêt à un banc), le
> deuxième est l'objet "banc"
>
> si on veux éviter les bouclons de stats entre "je compte une première
> fois les arrêts dotés d'un banc" et "les bancs", certains utilisent
> bench=separate (sur le modèle de sidewalk=separate), cela indique
> que l'arrêt à un banc et qu'il a été renseigné lui aussi par un objet
> cela a aussi l'avantage de pouvoir monter en qualité (celui qui veux
> ajouter des bancs n'a qu'à prendre les bench=yes et sait renseigner
> ceux qui sont traité)
> idem pour bin=separate shelter=separate
>
> dans tous les cas, je n'effacerais ni bench=yes ni amenity=bench,
> cela n'apporte rien d'autres que de faire du yoyo entre
> ajout/suppression puisque les 2 sont juste

Je ne connaissais pas "*=separate" et je vais l'adopter.
Jusqu'à présent, je pensais que c'était la même chose et je ne touchais
pas ce qu'avait fait un autre contributeur (même si c'était différent de
ce que j'aurais fait) pour ne pas intervenir sur le nombre, maintenant
s'il y a les deux déclarations j'utiliserais cet attribut qui ne fausse
pas les stats si pour avoir le nombre de bancs on additionne les deux.

leni


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

blef
In reply to this post by blef
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  ou 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_basket.
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

overflorian
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 <[hidden email]> 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  ou 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_basket.
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr


--

Florian Lainez

@overflorian

_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Grèves de Loire - un retour

ades.sept
bonsoir
je reprends ou déterre un vieux sujet à propos de grèves « permanentes » dans le lit de la Loire (au moins etre saumur et les Pts-de-Cé.

A l’époque j’avais posé le fait que des grèves permanentes, bin il n’y en a point.

Pour vérifier ce que je connais d’expérience je me suis amusé à cartographier les grèves telles qu’elles apparaissent sur les ortho libres disponibles, IGN (https://remonterletemps.ign.fr/telecharger?x=-0.319893&y=47.348157&z=12&layer=GEOGRAPHICALGRIDSYSTEMS.MAPS.SCAN-EXPRESS.STANDARD&demat=DEMAT.PVA$GEOPORTAIL:DEMAT;PHOTOS&missionId=missions.4971264) et Siel (http://www.centre-val-de-loire.developpement-durable.gouv.fr/les-donnees-du-siel-r557.html). La précision n’est pas tjs terrible, mais je pense que je suis à moins de 15m d’erreur.

L’idée était de voir si malgrès tout il était possible de déterminer des invariants. Ce en dehors des éléments qui à force de baisse du niveau à débit constantse sont pérennisés, il s’agit de quelques  ilôts ou zones de dépots alluvionnaires  végétalisés  et des" bras morts », mais ce  ne sont pas des grèves.
Une autre raison de vouloir vérifier ça c’est qu’actuelement des soit disants grèves permanentes sont déssinées, d’après l’ortho ign, l’année n de l’ortho ça marche, l’année n+1 ça se gate et l’année n+3 c’est n’importe quoi. Ou alors c’est juste pour faire joli… faut remarquer qu’il me semble que sur la Bd_Topo, hydro, récente normalement, ce sont les grèves de 2002 qui y figurent…

Pour ce qui concerne les grèves je n’ai pas réussi à déterminer par superposition des couches, des zones « traçables » de grèves « permanentes », d’autant que les dates de prise de vue sont parfois très rapprochées et que les variation à 1 ou 2 ans sont peux importantes.

Mais si quelqu’un veut bien jeter un coup d’œel au cas où ces infos seraient exploitable dans OSM…

J’ai mis ça en ligne sur uMap : https://umap.openstreetmap.fr/fr/map/loire-saumur-pts-de-ce-greves-1949-2016_546078#11/47.3342/-0.1967 le résultat est intéressant même si peu lisible sur uMap (si quelqu’un veut les shp et le pjt qGis suffit de demander, de même si quelqu’un veut connaitre le process d'amateur utilisé).




_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

cquest
In reply to this post by blef
Le 08/01/2021 à 15:08, blef 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.
>

Ce n'est pas un doublon:

- bench=yes indique juste que l'arrêt est équipé d'un banc (il y en a
même peut être plusieurs)

- amenity=bench cartographie ce(s) banc(s) en tant que tel(s), c'est un
niveau d'info en plus, pas en double


>   * 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.
>
C'est surtout bien plus simple pour les applis d'exploiter ce tag.


--
Christian Quest - OpenStreetMap France


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Christian Quest - cquest@openstreetmap.fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

Marc_marc
In reply to this post by overflorian
Le 08.01.21 à 16:04, Florian LAINEZ a écrit :
> 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.

je cherchais justement le message d'il y a environ 2 ans
ou la sncf allait changer son usage "collection" de ces relations.
p'tre qu'il serrait temps hein :)



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

Marc_marc
In reply to this post by blef
Le 08.01.21 à 15:08, blef a écrit :
> sur le rendu standard la présence d'un amenity=shelter près d'un arrêt
> masque ce dernier à certains facteur de zoom.

un exemple ? cela mériterait probablement un ticket pour améliorer le rendu



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

blef
Le 09/01/2021 à 18:10, Marc_marc a écrit :

> Le 08.01.21 à 15:08, blef a écrit :
>> sur le rendu standard la présence d'un amenity=shelter près d'un arrêt
>> masque ce dernier à certains facteur de zoom.
> un exemple ? cela mériterait probablement un ticket pour améliorer le rendu
>
>
>
> _______________________________________________
> Talk-fr mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk-fr

Ici, par exemple:

https://www.openstreetmap.org/node/5172950107 
<https://www.openstreetmap.org/node/5172950107>


_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
Reply | Threaded
Open this post in threaded view
|

Re: Arrêt de bus, comment tagger les équipements?

Bibi
Le 09/01/2021 à 18:29, blef - [hidden email] a écrit :

> Le 09/01/2021 à 18:10, Marc_marc a écrit :
>> Le 08.01.21 à 15:08, blef a écrit :
>>> sur le rendu standard la présence d'un amenity=shelter près d'un arrêt
>>> masque ce dernier à certains facteur de zoom.
>> un exemple ? cela mériterait probablement un ticket pour améliorer le
>> rendu
>
> Ici, par exemple:
>
> https://www.openstreetmap.org/node/5172950107

Nos spécialiste nous diront ce qu'il en est et comment corriger
proprement si c'est un problème de données.

Par comparaison avec un arrêt bien rendu
https://www.openstreetmap.org/node/1949826675, j'ai l'impression que le
problème vient de l'ajout de :

public_transport:version <https://wiki.openstreetmap.org/wiki/Key:public
transport:version?uselang=fr> 2



_______________________________________________
Talk-fr mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk-fr
12