Une partie des bouches portent des indications différentes selon si on
entre ou sort du métro.
Pour se conformer à cette situation, tout en cartographiant les zones
intérieures en surfacique, on avait utilisé les relations destination_sign.
Exemple à la gare de lyon :
https://www.openstreetmap.org/node/4086374120
Cette bouche porte le nom "Gare de Lyon" lorsqu'on vient de l'extérieur,
et "Sortie Rue Van Gogh" lorsqu'on sort.
Et sa relation destination_sign :
https://www.openstreetmap.org/relation/10054778
Stf
Le 14/02/2020 à 15:26, Francois Gouget a écrit :
On Fri, 14 Feb 2020, osm.sanspourr...@spamgourmet.com wrote:
[...]
https://www.sortiesdumetro.fr
<https://www.sortiesdumetro.fr/cluny-la-sorbonne.php> n'a pas des
données libres, mais ça peut permettre de voir la complétude. Après rien
n'empêche de demander s'ils acceptent une exception.
Ce site indique aussi quelles sorties disposent d'un ascenseur. Je ne
sais pas si la présence d'un ascenseur doit être représentée dans
OpenStreetMap mais ça serait sans doute une bonne idée d'indiquer quelle
sorties sont accessibles en fauteuil roulant.
Parfois les deux se combinent. Par exemple à Cachan deux des sorties ont
un ascenseur et sont donc accessibles en fauteuil roulant (+poussettes &
valises lourdes), tandis que deux autres nécessitent d'emprunter un
escalier.
Pour une sortie je suppose que la géométrie pourrait suffir à expliciter
l'accessibilité en chaise roulante, quoiqu'il n'y ait pas le moindre tag
wheelchair à l'horizon.
https://www.openstreetmap.org/node/6769102196
Mais pour l'autre sortie je ne vois pas trop comment une application
pourrait rattacher l'ascenseur à la sortie correspondante et traiter les
aspects chaise roulante :
https://www.openstreetmap.org/node/3823552596
Bon, et le champ name contient le nom de la station dans les deux cas
ce qui serait faux selon Noémie (et je suis d'accord). Par contre,
faut-il vraiment mettre le numéro dans le nom ou devrait-il être dans
le champ ref ? (pas exit_number apparemment) Ou les deux ?
[...]
266 noeuds sans tag ref. Est-ce que l'absence de ce tag a aussi une
sémantique (par exemple il n'y a qu'une sortie), ou est-ce que ce sont
des données manquantes?
ref est-il sensé être unique globalement ? (comme pour les
identifiants de boîtes aux lettres ou de transformateur) Parce que si
l'on met le numéro de sortie il y aura beaucoup de doublons 1, 2, 3...
1070 noeuds ont un attribut name, seulement 57 ont un attribut
destination. Est-ce que du coup on pourrait faire disparaître l'attribut
destination?
Non, destination est bon. C'est plutôt "name" qui est à vérifier et à
remplacer par destination le cas échéant.
Si je reprends la gare de Cachan, destination contient le nom des lignes
de bus en correspondance. Ça ne me semble pas devoir aller dans name.
Mais destination devrait-il indiquer les lignes de bus plutôt que les
noms de rues ?
Ce qui est bizarre aussi c'est qu'il a deux sorties côte à côte, une
pour le quai des RERs en provenance de Paris et l'autre pour ceux venant
de la banlieue ; et l'une indique "162;187;193;v3" et l'autre
"162;187;193". Pourtant venant de province c'est bien la sortie à
prendre pour attraper la Valouette (v3). C'est peut-être une bizarrerie
de l'affichage RATP. Il faudra que je vérifie.
Et qu'en est-il de découper le contenu de name, ou au moins d'en avoir
une version alternative découpée en plusieurs morceaux?
destination, ref et le nom de la station portée par la relation
public_transport=stop_area, oui c'est mieux (et au final on vire name,
Si à Cachan le champ destination contient bien les noms des lignes de
bus, alors il ne permettrait pas de reconstruire le nom des sorties qui,
il me semble, contiennent le nom de la rue où elles sont.
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
