> vous laisserez fr_arc_en_ciel sur tous les autres objets ?
Pourquoi ? Si c'est une référence Wikidata, a priori elle ne changera pas.
Et comme c'est un identifiant unique, on peut faire une modification
globale sans se poser de questions (à condition qu'il soit clair pour
les utilisateurs de cet identifiant que leur logiciels doivent être
paramétrables).
Mais je suis d'accord, ce n'est pas une bonne solution, ça me chiffonne
aussi.
C'est une permettant de limiter la casse.
Et je laissais la publication operator/operator:wikidata dans la ligne
(avec propagation plus simple des màj du fait de l'identifiant).
Sans, regarde le b... des noms du réseau en question sur Wikidata.
Arc-en-ciel ? Arc en ciel ? Réseau Arc en ciel.Réseau des cars
Arc-en-Ciel comme indiqué sur leur site ? RÉSEAU*ARC-EN-CIEL* comme
écrit sur les cars ? RÉSEAU *ARC-EN-CIEL* comme écrit sur les supports
informatique?
On dirait FR:AEC31, ça ne me générait pas .
J'ai pris l'exemple de la ligne 1, je vois le logo du département et lis
"/Tous ces services sont réalisés par REGIE DEPARTEMENTALE DES
TRANSPORTS
<https://www.haute-garonne.fr/annuaire/regie-departementale-des-transports>./"
Si tu préfères, gtfs:agency_id ou gtfs:agency_name mais quid des réseaux
sans GFTS publié ?
Mais une modélisation plus propre pourrait rendre le système plus simple.
Car un réseau est composé de lignes, de lignes unidirectionnelles et ces
lignes d'arrêts (pour Philippe : oui, éventuellement les lignes sont
composése de segments et les segments d'arrêts afin de simplifier les
variantes styles premier trajet du dépôt et dernier de retour au dépôt).
Comme déjà dit ici, avoir les plateformes permet sauf exception de
savoir ou s'arrête le véhicule. Préciser s'il s'arrête à l'avant (cas
général pour les bus et tram et les trains des gares terminus), au
milieu (cas des gares traversantes), pourquoi pas. Mettre une
stop_position si la plateforme est trop éloignée pour un calcul
automatique, pourquoi pas.
Et des points intermédiaires de passage afin de calculer proprement
l'itinéraire si un routeur ne sait pas faire le bon trajet (sachant que
c'est peu important pour l'urager, sauf pour les calculs de distance aux
prochains arrêts.
Le doc du STIF montre après assez bien comment modéliser les arrêts et
regroupements hiérarchiques d'arrêts.
Avec un tel système moins lourd que la V2, on a moins de soucis avec les
relations puisque les objets sont des essentiellement des relations et
des petits segments (plateformes) voir de simple nœuds.
Quand tu ajoutes un arrêt à une relation, tu le places en général afin
de minimiser la distance ou dans l'ordre inverse de la ligne de même
référence grand public si tu l'as.
Par exemple si tu as une ligne Brest-Paris et que tu ajoutes Rennes,
l'éditeur doit de proposer par défaut Brest-Rennes-Paris et non
Brest-Paris-Rennes parce que ce serait plus long.
Maintenant il peut te proposer directement Paris-Rennes-Brest pour le
sens inverse (ici il n'a pas à trouver les plateformes du côté opposé de
la rue).
Pour les segments, je parlais des parties optionnelles de ligne, il y a
aussi les parties partagées entre lignes.
La ligne C1
<https://www.openstreetmap.org/relation/399050#map=18/48.08864/-1.61807>
de la STAR (FR:STAR ;-)) et la 34
<https://www.openstreetmap.org/relation/1743068#map=18/48.08864/-1.61807>
se partagent la partie Avenue André Bonnin jusqu'à l'intersection
<https://www.openstreetmap.org/node/34486624#map=18/48.08864/-1.61807>
(public_transport=transit_point
<http://wiki.openstreetmap.org/wiki/Key:public%20transport?uselang=en> ?).
Alors pourquoi ne pas faire un segment jusque là, à partager entre les
deux lignes (ici il n'y a qu'un arrêt et deux points de passage, peu
intéressant ?).
Les lignes sont compositions de segments ayant des extrémités communes
(arrêt ou point de passage).
À propos de nom, cette ligne C1 s'est appelée 17, 7 et 1 (elle a juste
été prolongée et le numéro reflète son importance au fil du temps). On
est heureux que le nom ne soit pas dupliqué à chaque arrêt.
Jean-Yvon
Le 11/08/2017 à 08:17, Noémie Lehuby - noemie.leh...@zaclys.net a écrit :
Bonjour,
Excusez-moi de revenir là-dessus, mais continue de me chiffoner...
Si je comprend bien, vous mettez un identifiant de réseau dans le tag
network pour deux raisons :
* pour pouvoir stocker dans OSM des informations sur le réseau
(website, contact, etc) sans les dupliquer sur toutes les lignes
* pour avoir un identifiant unique et stable
Ça veut donc dire, si j'ai bien suivi, que si demain, dans un élan
d'originalité, le réseau Arc-En-Ciel est renommé TransHauteGaronne :
* vous mettrez à jour la relation network avec le nouveau nom
* vous laisserez fr_arc_en_ciel sur tous les autres objets ?
C'est vraiment ça ?
Le 07/08/2017 à 20:41, osm.sanspourr...@spamgourmet.com a écrit :
Le 07/08/2017 à 11:20, lenny.libre - lenny.li...@orange.fr a écrit :
Le 07/08/2017 à 10:50, osm.sanspourr...@spamgourmet.com a écrit :
(...)
Mais qu'est-ce qui empêche un outil de présenter CTRL - Compagnie
de transport de la région lorientaise (les /short name///et les
/label/) au lieu de Q2408086 ?
Cela veut dire que l'outil d’édition doit aller chercher la valeur
du wikidata quand le contributeur entre "CTRL" ? Le contributeur ne
saisit pas wikidata
Pas forcément. C'est une possibilité (Jo rappelle que le greffon
sous JOSM le fait).
Il peut aussi proposer les valeurs trouvées aux alentours (liste
modifiable).
Sur Lorient par exemple il pourra proposer CTRL car les arrêts aux
alentours sont en général de la CTRL.
D'accord avec Christian, une fois entré il ne faut pas que ça
entraîne une requête à une autre base mais être entré dans OSM.
Oui, mais je n'avais pas compris que cela :
"Le 04/08/2017 à 09:00, Christian Quest a écrit : Pour la majorité
usages, les données OSM doivent le plus possible se suffire à elles
même !"
Il me semble que le nom du réseau se suffit à lui-même, pas la
valeur du wikidata
"Le 04/08/2017 à 09:00, Christian Quest a écrit : Là où ça devient
utile c'est pour des outils comme osmose qui peuvent vérifier que
les autres tags (name, network etc) sont cohérents avec le tag
xxx:wikidata et donc aider à monter en qualité et cohérence à
l'intérieur même d'OSM."
Cela voudrait-il dire qu'il faudrait dans osm - "network:name" et
"network:wikidata" - et qu'osmose aille voir dans wikidata la
cohérence ? C'est un peu ce que disait Jo, non ?
Quand il dit que la cohérence entre le nom et le le wikidata peut
être vérifiée c'est bien qu'il stocke les deux.
Et donc c'est bien ce que dit Jo ou ce que je dis : l'utilisateur
choisit CTRL et on stocke à la fois le nom du réseau et son code
Wikidata. Après où on stocke exactement le nom (du réseau ici), ça
se discute mais ça ne change rien au principe.
Je n'ai rien contre le fait d'écrire CTRL au lieu de fr_CTRL par
exemple, mais il faut que les outils travaillant sur les réseaux
arrivent à distinguer le réseau de Lorient d'un autre. Je pense à
l'outil générant le squelette d'une ligne.
Je ne suis pas retombé dessus mais j'ai trouvé un bel article sur le
rendu des lignes en utilisant des données OSM :
https://medium.com/transit-app/how-we-built-the-worlds-prettiest-auto-generated-transit-maps-12d0c6fa502f
Jean-Yvon
_______________________________________________
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
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
