[OSM-talk-fr] ERDF (et RFF) ont changé de nom

osm.sanspourriel at spamgourmet.com osm.sanspourriel at spamgourmet.com
Sam 4 Juin 20:40:14 UTC 2016


Le 2016-06-04 à 20:44, DH - dhelfer at free.fr a écrit :

> Le 04/06/2016 19:43, osm.sanspourriel at spamgourmet.com a écrit :
>> le 2016-06-04 à 19:18, DH - dhelfer at free.fr a écrit :
>>> Le RFN n'est pas un réseau de voies ferrés donc ? what else ?
>> Un réseau implique usuellement une topologie, là c'est juste "est 
>> opéré par". 
> Ah bon ? Selon toi, les trains soit, sortent du RFN le temps de 
> trouver le prochain tronçon, soit demande la permission à un autre 
> opérateur (lequel ?) pour retraper le RFN ?
> Je te rassures, il n'en est rien, le RFN EST topologique. Et il n'est 
> pas "juste" opéré par ; juridiquement SNCF Réseau en est aussi le 
> propriétaire (avec tous les emmerdements qui vont avec)
Contrairement à Endis qui n'est que le concessionnaire au même titre que 
VéOLia et consorts pour l'eau.
Oui, bien-sûr RFN est un réseau au sens topologique, ce que je veux dire 
c'est que si tu mets tout en vrac dans une relation, tu n'as plus grand 
chose. En tous cas pas un réseau.

Jérôme, même sur la ligne Carhaix-Guingamp, qui n'est pas opérée par la 
SNCF le rail est opéré par SNCF Réseaux.

 > 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.
Heu, j'ai l'impression qu'actuellement en France on a les voies.

>>> Est-ce une bonne pratique de mettre systématiquement oneway=no sur 
>>> toute la voirie standard ?
>> 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. Quand il y a besoin de mettre un oneway=yes il FAUT (MUST) le 
> mettre sur la portion qui va bien. Aucun ligne d'infrastructure 
> ferroviaire (au sens rails, aiguillage, etc...) ne peut avoir d'autre 
> opérateur[propriétaire que SNCF Réseau (sur le RFN puisque qu'il y a 
> des rails propriété d'associations, d'industriels, etc. d'où l'intérêt 
> de la super-relation RFN ;-).
> La différence c'est qu'Il faut (SHOULD) factoriser tout ce qui peut l'être
Pour quoi faire ? On peut factoriser l'ensemble des "rue de la Mairie" 
pour ne mettre plus de noms sur les tronçons et les associatedStreet. 
Mais ça n'a aucun sens.
C'est valable pour l'ensemble des attribut=valeur. Pourquoi pas une 
relation des routes à 90 km/h ?
Les éditeurs signalent quand des relations ne sont que partiellement 
chargées.
Imagine que l'on télécharge des relations complètes. Et hop, voici tout 
le RFN chargé alors que l'utilisateur voulait juste modifier un jardin 
le long de la voie.

>> Tu ne veux pas mettre oneway=yes au niveau de la relation et 
>> oneway=no sur les tronçons bidirectionnels ?
> non
>> 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. 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.
> j'arrive de plus en plus à distinguer l'éditeur utilisé (JOSM ou pas) 
> simplement au fait que certaines valeurs sont remplies ou pas. Suivant 
> cette logique, les mêmes réalités sont potentiellement représentées 
> par un ensemble de tags différents suivant l'éditeur utilisé. Des fois 
> c'est bien quand ce sont des éditeurs spécialisés (Mapcontrib), des 
> fois pas.
On est d'accord : il vaut mieux s'entendre sur les valeurs à mettre.
Par exemple je vois que sur la ligne Carhaix-Guingamp tu as remonté 
l'info ref et gauge notamment au niveau de cette relation. Ça a du sens 
(c'est plus pratique pour le train que la gauge soit constante) et cette 
relation a un sens.
>>> 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".
>> Quand tu te trouves du côté de Xouaxange 
>> <http://www.openstreetmap.org/#map=15/48.7017/7.0052&layers=T>, c'est 
>> bien pratique de savoir si le train roule à gauche (comme en France 
>> car Napoléon ne croyait pas au développement du train) ou à droite 
>> (comme en Allemagne car la voie a pris de l'ampleur quand 
>> l'Alsace-Moselle était en Allemagne).
>> 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.
>>
> Pas besoin : je travaille chez SNCF Réseau à Strasbourg : je crois 
> connaitre le sujet assez bien quoique toujours preneur d'autres regards.
Toi non, le "tu" était générique : l'utilisateur d'OSM.Qui lui ne sait 
pas forcément.

Un intérêt d'avoir les sens de circulations usuels (même si 
l'utilisateur lambda ne conduit pas de train) c'est aussi que les 
logiciels style Mapillary suggèrent les oneway manquants. Sur une voie 
exprès ou une autoroute on a oneway=yes, ça ne veut pas dire qu'en cas 
de travaux on ne roulera pas sur une voie de l'autre côté, à contresens 
selon OSM. Mais dans le bon sens selon openDataBase ;-).

Le 2016-06-04 à 21:31, Jérôme Seigneuret - jseigneuret-pro at yahoo.fr a 
écrit :
> 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.
Tu as aussi le retour d'expérience : quand un train de déchets 
nucléaires déraille dans un aiguillage parce que l'aiguillage n'a pas 
été vérifié aux rayons X, plutôt que de vérifier les aiguillages on 
préfère faire passer les trains de déchets nucléaires au plus droit.
> 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.
Je crois que côté rail en France, dans la partie publique il n'y a pas 
photo, c'est SNCF Réseaux. Quoique avec les tram-trains, on peut 
imaginer que des tronçons plus exploités par des trains lourds soient 
exploités dans le futur par la compagnie de tramways. En espérant que la 
politique de prix ne fasse que comme à Karlsruhe l'exploitant du réseau 
de trams-trains ne construise une voie parallèle à la voie de la DB car 
trop chère.
Le hiatus vient du fait que Denis ne veut le mettre que dans une super 
relation. Pour moi le niveau le plus haut raisonnable c'est la ligne.
Sur l'implication dettes donc ça restera à SNCF Réseaux, ce n'est pas 
parce qu'un service n'est pas rentable qu'il n'est pas rentable pour 
l'opérateur. Demande à Keolis ;-).
C'est vrai que l'évolution RFF/SNCF Réseaux est dans la direction 
opposée de celle de ERDF/Endis.
Mais ce qu'il faut c'est cartographier ce qui est, pas ce qu'on aimerait 
qui soit.

Tiens je vois qu'au niveau des passages à niveau on a des clés RFF (mais 
pas d'operator) :
http://www.openstreetmap.org/node/1145514247
level_crossing:RFF:type 	PN public pour voitures avec barrières ou 1/2 
barrières non gardé à SAL 2 et SAL 2B
ref:RFF:ligne 	485000


Continuons sur cette liaison Carhiax-Guingamp, je vois
des gares
http://www.openstreetmap.org/node/3467582893
avec pour operator 
<http://wiki.openstreetmap.org/wiki/FR:Key:operator?uselang=fr> SNCF.
Or la ligne est opérée par la CFTA. Quid des gares ?

Jean-Yvon
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160604/600e95b3/attachment.htm>


Plus d'informations sur la liste de diffusion Talk-fr