Résumé à la vdct : KISS

Le 23/08/2017 à 20:59, Noémie Lehuby - noemie.leh...@zaclys.net a écrit :
Le 22/08/2017 à 22:52, Philippe Verdy a écrit :
> L'ennui c'et que toutes les applications qui ont commencé à utiliser network=* ont supposé que le nom indiqué derrière était unique, ce qu'il n'est pas. En fait ils voulaient que ce soit bien un identifiant.

On parle de quelles applications ?
Moi j'en connais pas bcp qui utilisent le tag network des relations route ou route_master (voire même : pas bcp qui utilisent les relations route ou route_master).
Noémie, tu m'enlèves le pain de la bouche.
Car j'allais poser la question.
Je ne connais personnellement que Overpass API qui a l'interface sketchline pour produire des lignes de transport.
https://wiki.openstreetmap.org/wiki/Overpass_API/Public_transport_examples

Fonctionnalité si bien cachée que je ne trouvais pas le point d'entrée <http://overpass-api.de/public_transport.html> de l'application (en fait il ne fallait pas partir du wiki mais de la page principale, je corrige le wiki). Je découvre aujourd'hui après le style allemand et italien le style français appelé paris :
http://overpass-api.de/api/sketch-line?ref=a&network=FR:STAR&style=paris
Pas mal !
Et pour les lignes identiques, j'ai fini par avoir une idée qui me semble être simple (et donc bonne). Suspense...

Personnellement, quand je fais des extractions de données transports, je ne m'attends pas à ce que le nom soit unique. S'il y a deux réseaux STAR ou Arc-En-Ciel ou SITUS, ben je veux avoir deux occurrences dans mes données. C'est la réalité du terrain, ça me semble normal de retrouver cela dans OSM.

En fait quelqu'un disait que les noms de villes étaient aussi multiples et que ça ne nous dérangeait pas. Dans l'API précédente il nous propose en cas de réseaux de même nom la clé operator. Si je prends la CTRL <https://fr.wikipedia.org/wiki/Compagnie_de_transport_de_la_r%C3%A9gion_lorientaise> (Lorient) pas moins de 5 opérateurs pour les bus ou cars (Philippe me dira qu'ils sont sans toutes tous délégataires d'un seul, possible mais si un contributeur vois des car Kerjan assurer le transport scolaire il mettra operator Kerjan, pas Keolis Lorient). Subtilités :
- 5 lignes maritimes gérées par Keolis Maritime Lorient
- une ligne maritime sans doute cogérée avec TBK entre les Bas-Pouldus c'est à dire les port de Guidel-Plages et du Pouldu.
Donc l'API proposée qui demande un tag operator après un network tu oublies.

Le nom public c'est simple (CTRL, TBK, c'est écrit sur les véhicules et sur les arrêts).
Et... le lieu c'est simple pour OSM.
Or on est sur Overpass qui comprend facilement des bbox et des zones géographiques. "network=fr_ctrl in Bretagne" avec l'assistant overpass-turbo donne bien le réseau CTRL. Si demain l'API supporte bbox et/ou geocodeArea, ça permet de mettre le nom commercial dans network, et d'avoir une API plus facile à utiliser pour monsieur tout le monde : l'unicité du nom comme pour la ville vient de la précision de la localisation (Brest, Bretagne ou Brest, Belarus comme Arc-en-ciel, Haute-Garonne). network=fr_ctrl in "Lorient Agglomération" <http://overpass-turbo.eu/s/rcO> marche aussi.

On peut ajouter un tampon optionnel (around, ça existe déjà) pour traiter des transports hors zone de compétence stricte (ci-dessus, Le Pouldu est dans le Finistère et non dans Lorient Aqglomération).

Parce que les noms sont en entrée libre, je suggère d'avoir un network:wikidata afin de faire plus facilement du contrôle qualité. Et si on ne veut pas ajouter un Wikidata, on peut toujours au lieu d'avoir un Qxxx mettre un Oxxx (identifiant unique OSM, à mettre quelque part par exemple sur le wiki page transports public).

Ce qui répond aux besoins exprimés par Philippe (unicité) et aussi bien qu'aujourd'hui (où nulle part on n'a la liste des identifiants utilisés). Le jour ou il y a un wikidata, il suffit de remplacer les network:wikidata=Oxxx par network:wikidata=Qyyy.

Quant à la lenteur supposée par Philippe, elle suppose que l'on est bourrin et qu'on travaille sans cache. De plus la solution proposée n'exclut pas la relation network.

Jean-Yvon
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Reply via email to