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 ?
C'est toute la différence entre des données relationnelles avec des
liens explicites et des données géographiques, avec des liens
implicites. Dans le premier cas, il n'y a pas ambiguïté, dans le second,
il faut faire un calcul géométrique et on n'est pas toujours sûr du
résultat.
La modélisation sert justement à rester autant que possible dans
l'explicite non ambigu.
[...]
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...
Non ref n'a pas vocation a être unique... les numéros de routes sont un
bon exemple !
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 ?
Qu'y a-t-il sur le terrain, c'est à dire sur les panneaux qui signalent
les sorties ?
Une sortie débouche le plus souvent sur plein de choses... et la
signalétique n'est pas homogène. Parfois on aura un nom de rue, des N°
de lignes de bus, voire le nom d'un monument !
Là, je pense qu'il faut repasser en géo implicite et pas en description
explicite.
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.
Les "noms" sont ici plutôt un repère pour les différencier et plus
compréhensibles que des numéros complètement arbitraires.
--
Christian Quest - OpenStreetMap France
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
