> SNCF Réseau est gestionnaire de l'infrastructure et, à ce titre, détient
> le monopole. Ce monopole n'est pas prêt d'être partagé puisque la seule
> chose à partager c'est la dette.
>

>
Le débat est lié au terme utilisé pour *operator *sur les linéaires ou les
relations.
Le monopole n'est que temporaire (à mon avis si l'Europe continue) et n'est
valable que sur le réseau national et non sur les réseau locaux existants
(il y a toujours des exceptions) mais bon quand on a un gars sur le terrain
pour suivre des prestataires, on peut se demander si l'intérêt de celui-ci
quand la maintenance est sous-traité. Les gens du terrain parlent toujours
trop... (Mais bon, l'Alsace c'est un autre monde en France. ;-) )

Dans l'électricité il n'y a pas vraiment de monopole mais un système de
concession comme pour les autoroutes et l'aériens.

Quand à la dette il y a une différence entre être possesseur du réseau et
en faire la maintenance. Il y a encore peut c'est RFF qui possédait cette
dette (la SNCF avant ça) et SNCF Infra qui en avait la gestion (pourtant la
dette c'est pas l'infra qui la supportée)  Bref c'est juste un jeu
d'écriture pour cette histoire de fusion comme ça l'a été à la création de
RFF. On a pas fini de voir la fin du tunnel sur l'ouverture à la
concurrence imposé par l'Europe. >>> AUTRE DEBAT POUR UN AUTRE SUJET ;-)

Un réseau implique usuellement une topologie, là c'est juste "est opéré
> par".
>
Oui mais le niveau de topologie dépend de la précision des données saisies
et de l'homogénéité que l'on peut apporté. Il y a qu'à voir le système
routier avec les schémas coexistants ou la gestions des carrefours
complexes, les relations pour éviter de pouvoir faire des demi-tours sur
les voies de sortie/entrée de rond-points.... Quelle est la part qui est à
imputer au soft et celle à gérer dans la base?

> Est-ce une bonne pratique de mettre systématiquement oneway=no sur toute
> la voirie standard ?
>
> Non je pense que quand on a 90% des cas où c'est une valeur implicite. Il
faut préciser les autres cas (méconnaissance, ou oui, ou cas particulier
dans des conditions de service) ( Le wiki doit préciser ces cas et servir
de notice pour que les applications soient en capacité d'exploiter les
données. C'est le cas des routes. Là où je suis d'accord, c'est quand on a
trop d'effets de bord ou de cas possible différents et des cas qui implique
trop de requête pour exploiter correctement cette information.

oneway=no ce n'est pas pour moi l'un des cas les plus visible surtout que
c'est plutôt dans ce cas du oneway=reversible. Il y a des gares où le chef
de gare doit appeler la gare suivante pour que le train puisse partir. La
signalisation est dans les deux sens. Dans tous les cas où la signalisation
est unidirectionnel on aura un oneway=yes (est peut-être
oneway:conditionnal=no @ {condition à définir} )
A savoir que dans la plupart des cas, on dispose que de la ligne dans osm
et non les voies. Donc difficile de mettre les bons termes.

> oui, car il a des tronçons à voie unique. De plus si par tronçon tu ne
> sais dans quel sens est le sens unique, on a avoir des accidents ;-(.
>

Non car la carto n'est pas une donnée à suivre dans les système
opérationnels. Quand j'étais à Réseau on avait un SI lignes et non voies et
je suis pas sûr qu'actuellement un SI voies soit opérationnel.


> Tu ne veux pas mettre oneway=yes au niveau de la relation et oneway=no sur
> les tronçons bidirectionnels ?
> C'est à l'éditeur de proposer un oneway=yes, le contributeur, soit il le
> sait, soit il ne le sait pas. S'il le sait, autant qu'il l'entre. S'il ne
> le sait pas, il vaut mieux que l'éditeur ne fasse pas d'hypothèse.
>

C'est bien pour cela qu'au niveau aérien il n'y a rien et que le wiki se
dégage de responsabité et dit clairement que c'est pas pour un usage
opérationnel  ;-) C'est pas sûr comme système et heureusement c'est pas
n'importe qui qui roule avec un train et c'est pas toi qui choisi
l'aiguillage :-) le système ferroviaire n'utilise pas un SIG pour choisir
l'aiguillage.
Tu veux un GPS ferroviaire XD non je déconne.


> Bon tu me diras qu'on n'est pas trop à la créations de voies ferrées en
> France (sauf LGV) et plutôt à arrêter les lignes bidirectionnelles.
>

Arrêter oui et non. Ne plus en créer ok. Les fermer sûrement. Réduire les
systèmes d'aiguillages complexe carrément! Vu qu'avec la mise en service
des systèmes de contrôle d’aiguillage électronique on a simplifié et perdu
des connaissances dans ce domaines avec le temps, on sait pas faire donc on
simplifie.

La bidirectionnalité n'est pas seulement lié à l'usage par défaut mais à
l’existence des systèmes physiques permettant de gérer la signalisation.
Dans le cas de maintenance sur les voies il y a des cas où le train peut
rouler sur la voie de gauche comme à droite. Dans le cas ou la ligne
possède plus de 2 voies ça se complique encore. Celle du centre peut servir
pour le sens gauche ou droite. La voie de droite ou de gauche peut être une
voie réservé pour un usage de service.
Bref c'est pas si simple. Il y a des choses comme le fait de pouvoir rouler
à vu au pas qu'il ne sera pas possible à mettre dans la base. D'où la
limite à définir entre ce qui doit ou peut être saisi.

Il y a des valeurs par défaut décrites dans le wiki (à défaut dans le sens
commun des contributeurs/_utilisateurs) ; il revient aux exportateurs de
transcrire ces valeurs par défaut dans des produits "standardisés".
Ca je suis OK. Encore faudrait-il qu'il y ait un groupe de travail avec des
opérateurs par métier afin d'évaluer les clés nécessaires, les valeurs par
défaut et les limites du système comme les moyens à mettre en oeuvre pour
alimenter et maintenir le système. C'est pas sur de l'interprétation
photographique que l'on peut définir correctement les valeurs des clés.

Je crois que Jérôme te fera un topo sur l'intérêt de ne pas reposer sur des
> valeurs par défaut.
>
En fait, comme je le dis au début, l'intérêt peut se faire sentir quand il
y a des zones flous, des ambiguïtés possible ou trop de cas de figures.
Mais en effet le wiki ne mets pas assez en avant les imbrications et les
valeurs implicites des clés pour que les contributeurs n'ai pas à se poser
de questions. On va faire un travail en ce sens coté système routier sur
Montpellier (afin d'homogénéiser les pratiques de saisie)

Je ne prendrais pas parti de toute-façon sur les clés du ferroviaire car je
ne les exploites pas (je ne suis plus à la SNCF). Je suis plus chiant sur
le routier car j'en fais un usage et encore plus sur le vélo. Je peux juste
donner un avis averti pour avoir bosser pour l'entité qui a conçu la base
Réseau à L'Infra.

Maintenant @Jean-Yvon et @Denis on peut aussi recentrer le sujet sur la
valeur du tag *operator *je pense que c'est le sujet de départ. Pour le
reste on peut créer un autre sujet qu'il sera plus pertinent d'alimenter.

Bonne Soirée
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Répondre à