<div dir="ltr"><div>Hello,</div><div>N'ayant pas grand chose à ajouter, je n'ai pour l'instant pas pris part à la discussion.</div><div><br></div><div>Il me semble en effet que la cohabitation entre tags sur l'arrêt ou objets à proximité va perdurer.</div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">mettre tout dans un stop_area conduit à avoir une relation avec des<br>
milliers de membres pour la gare du nord à Paris, sans que la plus-value<br>
saute aux yeux (les relations ne sont pas des collections).</blockquote><div>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.<br>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Les relations... sont souvent de fausses solutions ;)</div></blockquote><div>Je confirme. FBI : Fausse Bonne Idée.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 8 janv. 2021 à 15:08, blef <<a href="mailto:bernard.lefrancois@free.fr">bernard.lefrancois@free.fr</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">
<div>
<div>Bonjour,</div>
<div><br>
</div>
<div>Merci pour vos avis.</div>
<div><br>
</div>
<div>Si je résume:</div>
<div><br>
</div>
<div>
<ul>
<li>Inclure les shelter, bench, bin séparés dans la relation <b>stop_area</b>?
Personne n'y semble favorable, moi non plus.<br>
Dommage que le <a href="https://wiki.openstreetmap.org/wiki/FR:Tag:public%20transport=platform?uselang=fr" target="_blank">wiki/FR:Tag:public_transport=platform</a>
ou <a href="https://wiki.openstreetmap.org/wiki/FR:Key:public_transport" target="_blank">wiki/FR:Key:public_transport</a>
préconise de le faire: <i>Le lieu d'attente est normalement
associé aux autres éléments de l'arrêt (</i><i>stop_position</i><i>,</i><i> </i><i>bancs</i><i>,</i><i> </i><i>abris</i><i>,
...) à l'aide d'une relation de type</i><i> </i><i>public_transport=</i><i>stop_area</i></li>
</ul>
</div>
<div>
<ul>
<li>Garder les deux indications: shelter=yes sur l'arrêt
(platform) et amenity=shelter sur un node ou way séparé?<br>
Ç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.<br>
Le wiki (encore lui) recommande: <i>shelter=yes indique si un
abri est présent (s'il n'est pas déjà tagué avec
amenity=shelter)<br>
</i>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.<br>
Dommage encore que cette solution ne soit pas documentée, et
sans doute pas prise en compte par les appli genre Osmand et
autres.<br>
<br>
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.</li>
</ul>
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.<br>
</div>
<div><br>
</div>
<div>Si vous avez d'autres idées...<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>Le 07/01/2021 à 18:46, blef a écrit :<br>
</div>
<blockquote type="cite">
<p>Bonjour</p>
<p>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 <b>platform</b>,
par un nœud avec en plus de l'attribut <b>public_transport=platform</b>
les différents attributs décrivant l'équipement de l'arrêt: <b>shelter=yes/no</b>,
<b>bench=yes/no</b>, <b>bin=yes/no</b> etc.<br>
J'avais aussi créé systématiquement un relation <b>stop_area</b>
pour chaque arrêt.</p>
<p>Au fil du temps, d'autres contributeurs ont ajouté séparément
certains de ces équipements, par exemple sur un nœud (ou way) <b>amenity=shelter</b>
+ <b>shelter_type=public_transport</b> ou <b>amenity=waste_baske</b><b>t</b>.<br>
D'après le wiki, et pour respecter le mantra <i>One feature,
One OSM element</i>, les attributs <b>shelter=yes/no</b>, <b>bench=yes/no</b>,
<b>bin=yes/no</b> devraient être supprimés sur le nœud <b>public_transport=platform</b>.<br>
De plus les nouveaux objets devraient être ajoutés comme membres
de la relation <b>stop_area</b>.</p>
<p>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.<br>
Même en allant regarder dans la relation <b>stop_area</b>, il
faudrait associer correctement chaque équipement avec la <b>platform</b>
concernée, pas facile à faire et ça m'étonnerait que ça se
fasse.</p>
<p>J'aimerais connaitre votre avis sur la question pour décider de
la meilleure méthode à appliquer.</p>
Merci. <br>
<fieldset></fieldset>
<pre>_______________________________________________
Talk-fr mailing list
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a>
</pre>
</blockquote>
<p><br>
</p>
</div>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">
<p style="margin-bottom:0cm">
</p><p style="margin-bottom:0cm"><font color="#333333"><font face="arial, helvetica, sans-serif"><font style="font-size:11pt" size="2"><b>Florian
Lainez</b></font></font><br></font></p><img src="http://twitter.com/favicon.ico"><a href="http://twitter.com/overflorian" target="_blank">@overflorian</a><br></div></div>