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

2016-06-07 Par sujet François Lacombe 
Hello tous,

C'est cool toutes ces contributions !
Pour ma part, pas le temps en ce moment de traiter tous les sujets

En ce qui concerne l'utilisation de wikidata, ca serait une sacrée
avancée de pouvoir coupler (modalités visiblement à définir) des
objets OSM à des objets Wikidata. Globalement on pourrait supprimer
tous les noms propres de la base !
Mais il n'y a pas que la base : les outils devraient à minima afficher
un intitulé intelligible à l'utilisateur tout en maintenant l'id
wikidata en arrière plan.
A moins que l'API OSM évolue et gère lui-même ces jointures en
s'associant de manière plus prononcée à wikidata... ce qui est encore
moins évident.


+1 sur l'idée suivante : même si nous indiquons "ERDF", "Enedis",
"SNCF Réseau" dans operator=* c'est évidemment une référence déguisée.
La valeur correspond aussi bien à l'humain qu'à la machine.
Dans un traitement d'import dans une base métier, la 1ere chose à
faire est de remplacer ces chaines de textes par une valeur servant de
clé étrangère avec une table annexes d'exploitants qui expose un tas
d'autres propriétés de l'exploitant en question.

Dans l'immédiat, c'est dur de savoir vraiment quoi faire...
["operator"~"Enedis|ERDF"] ca marche aussi dans overpass, même si
c'est éloigné du propos de départ.

Joker sur la question des relations :)
C'est moins pratique en tant que consommateur d'aller chercher aux 4
coins du fichier pour connaitre une propriété récurrente (dans les
relations parentes mais aussi le changeset).

Jean-Yvon, par rapport à l'un de nos premier mails sur la question,
sur le nom du poste MLTVULCA.
L'utilisation de ref=* n'est pas bonne ici, il faut indiquer MLTVULCA
dans name=*.
MLT. Vulca est une entreprise de vulcanisation située juste à côté du
poste en question, c'est son nom qui est indiqué sur le poste de
livraison.

Le 6 juin 2016 à 23:04,  a écrit :
> François j'ai vérifié, on a des transformateurs privés qui ont la plaque 
> Electricité de France (fort défraichie) dont les supports du nom cabalistique 
> ont été vidés (c'est nouveau, suite au remplacement de l'arrivée) et qui ne 
> sont pas
> gérés par Enedis. Enedis n'est responsable que jusqu'au bout du câble.

Pour le cas des postes privés (ex tarifs vert, livraison en HTA 20kV
triphasé), en effet l'exploitant est la société privée titulaire du
contrat de livraison.
Le distributeur (Enedis ou la régie locale) dispose des interrupteurs
d'entrée de poste, puisque le poste en question peut être alimenté
depuis plusieurs sources, en antenne ou coupure de boucle/artère.
Ces postes sont néanmoins connus du SI distributeur, sont nommés et
identifiés de la même façon, avec les même codes.
Bon, operator=Enedis est passable, il y a des composants à l'intérieur
exploités par Enedis. owner=* par contre, c'est systématiquement le
client.

En résumé : power=substation + substation=industrial + operator=Enedis
ou régie + voltage=2;400 + owner=le client
Si le contributeur est capable de faire la différence avec un poste de
distribution publique (raccordement de clients en 400V/220V mono ou
tri par le distributeur) :
power=substation + substation=minor_distribution + operator=Enedis ou
régie + voltage=2;400 + owner=autorité concédente, syndicat d'elec
ou autres.

Bonne soirée :)

François

--
François Lacombe

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2016-06-06 Par sujet osm . sanspourriel 

Le 2016-06-06 à 20:27, Éric Gillet - gill3t.3ric+...@gmail.com a écrit :
Le 6 juin 2016 à 12:45, Christian Quest > a écrit :


C'est très machine friendly mais par du tout human friendly... et
pour l'instant les contributeurs sont plus des humain que des
machines ;)


Pas sûr, en plus des problèmes de performance et de complexité 
(relative) de mise en oeuvre, devoir dépendre sur une base de données 
externe ajoute des contraintes en terme de disponibilité, et pérennité 
d'OSM.


Mais oui je conçois que l'idée soit agréable dans son concept :)
Oui, assez d'accord avec Éric et Cie. Mais on ne dépend pas forcément de 
la disponibilité de Wikidata.


D'abord un aparté. /Ils arrivent à faire une vidéo de présentation 
 sans expliquer l'origine d'enedis (sans 
accent, contrairement à ÉNErgie DIStribution), sans expliquer comment ça 
se prononce. Par défaut en français comme euneudix. Super pour les moins 
capables qui se feront taxer de neuneu dix (tu es un enedis : tu es un 
neuneu//^dix //). Si ça se prononce comme Haine//^Dix //, pas beaucoup 
mieux.//
//Je trouve ce pubeux extraordinaire car faire un effet de dominos alors 
que l'écroulement du réseau (ce que doit absolument éviter Enedis) se 
fait par effet domino, privant par exemple 10 millions de Français et 
seulement 8 d'Allemands parce qu'un gestionnaire de réseau a coupé 
volontairement et après prévenance, notamment du principal producteur 
appartenant au même groupe et qui pourtant a produit sans en tenir 
compte, entraînant cette effet domino. Fort le mec sachant qu'en France 
aussi un producteur (EDF) et un opérateur de réseau (Enedis) font partie 
de même groupe... Et montrer la continuité de service au delà du 
continent alors qu'EDF SA et ERDF sont en pleine consanguinité à l'Ile 
de Sein (ERDF faisant des réunions avec et uniquement avec EDF), chapeau 
bas !/

Fin de l'aparté.

Alors nom direct ou pas ?
Nom direct = simplicité (et effectivement je suis pour utiliser en 
operator ou brand les noms effectivement pratiqués, donc SNCF Réseau pas 
Société Nationale des Chemins de fer Français Réseau)

Wiki data = stabilité ?

Je vois que SNCF Réseau a son wikidata (Q21605526 
).
Bien, mais je vois qu'il existe en deux langues (FR et EN), a une petite 
description dans les mêmes mais a des pages wikipédia en FR et... DE.
Et cet EPIC est défini comme " établissement public à caractère 
industriel et commercial (Q3591583 
) "
Les noms alternatifs (comme EPIC) sont mis en vrac alors que sous OSM ce 
serait un short_name.


Il me semble intéressant d'avoir des description de Wikidata dans OSM.

C'est à dire que les références vers des brands, operator et quelques 
autres seraient des liens vers des nœuds ou relations OSM de type Wikidata.
Je ne sais si on doit imposer une géométrie (sinon on risque de casser 
le modèle) ou considérer non que ce sont des nœuds mais des relations 
spéciales (couples attributs/valeurs sans membres (forcément ?) mais 
avec un attribut wikidata) ?


Bien-sûr l'utilisateur lambda doit pouvoir écrire SNCF Réseau ou Enedis, 
c'est à l'éditeur de faire la correspondance.

En fonction du contexte le choix peut être fortement guidé.
Par exemple l'objet Q3587594 (Enedis) doit avoir
name=Enedis
wikidata=Q3587594
old_name=ERDF
old_name:1=Electricité Réseau Distribution France
old_name:2=EDF
old_name:3=Electricité de France
(je sais ERDF et EDF sont des anciens short_name, 
short_name:-2016-06-01=ERDF serait toujours faux mais plus précis).


Vous aurez compris, je vois plus ces objets par création via intégration 
plus que par import brut.
En gardant la date de dernier import on peut facilement avoir des outils 
pour les mettre à jour (facilement : je parle du niveau conceptuel ;-)).


On peut même faire référence la liste des gares bretonnes en indonésien 
! Q3249799 .
Juste pour dire que les wikidata qui nous intéressent ne sont qu'une 
partie de ce qui existe : un import massif n'aurait pas de sens.
De même un remplacement systématique par des relations (comme un 
renommage systématique) doit être surveillé : import versus intégration.


Plusieurs avantages :
- on reste en OSM, sans dépendance permanente vers la base Wikidata.
- on garde notre modèle (pas de noms en vrac, mais des noms par langue, 
des noms locaux, des noms courts, des noms internationaux...) donc les 
outils suivent (surtout si la valeur est une référence vers une relation).


Peut-être qu'il faut avoir des ref:rel; brand:rel pour savoir que la 
valeur est une relation dont le nom doit être affiché.


Exemple d'affichage sous OSM de la sous-station : 
http://www.openstreetmap.org/node/1739065627

Actuel :
name  
Fontaine de Kereven
operator

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

2016-06-06 Par sujet Éric Gillet 
Le 6 juin 2016 à 12:45, Christian Quest  a écrit :

> Le 06/06/2016 à 12:30, Nicolas Dumoulin a écrit :
>
>> Salut,
>>
>> Le Fri, 3 Jun 2016 19:28:51 +0200,
>> François Lacombe  a écrit :
>>
>>> Quid de proposer au DWG de faire une migration en masse ?
>>> Plutôt facile à réaliser : overpass => query sur operator=ERDF => JSOM
>>> ctrl+A => operator=Enedis => Upload
>>>
>>> Le principal enjeu est l'information de la communauté et la mise à
>>> jour des scripts de consommation.
>>>
>> Le cas se présente régulièrement : comment gérer le renommage en masse
>> sans casser les dépendances des outils aux noms dans la base OSM.
>> Et là, suite à la fantastique présentation de wikidata à Clermont, je
>> me dis et je vous transmets :
>> Si on mettais operator=wikidata:Q3587594 plutôt que Enedis ?
>> https://www.wikidata.org/wiki/Q3587594
>>
>> Ça implique aux outils de représentation d'utiliser wikidata, et je
>> suis d'accord ça alourdi un peu le processus.
>> Mais sinon, ça simplifierai beaucoup de chose :-)
>>
>> C'est dans la même veine que l'idée de Jean-Louis lors de sa
>> présentation : déplacer dans wikidata les histoires de liste de noms
>> alternatifs à rallonge. Wikidata est conçu pour ça, et on est vite
>> limité dans OSM avec nos quelques variantes de *_name et name_*.
>>
>> C'est pas évident à mettre en place, mais je trouve cela très séduisant.
>>
>>
> C'est très machine friendly mais par du tout human friendly... et pour
> l'instant les contributeurs sont plus des humain que des machines ;)
>

Pas sûr, en plus des problèmes de performance et de complexité (relative)
de mise en oeuvre, devoir dépendre sur une base de données externe ajoute
des contraintes en terme de disponibilité, et pérennité d'OSM.

Mais oui je conçois que l'idée soit agréable dans son concept :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2016-06-06 Par sujet Christian Quest 

Le 06/06/2016 à 12:30, Nicolas Dumoulin a écrit :

Salut,

Le Fri, 3 Jun 2016 19:28:51 +0200,
François Lacombe  a écrit :

Quid de proposer au DWG de faire une migration en masse ?
Plutôt facile à réaliser : overpass => query sur operator=ERDF => JSOM
ctrl+A => operator=Enedis => Upload

Le principal enjeu est l'information de la communauté et la mise à
jour des scripts de consommation.

Le cas se présente régulièrement : comment gérer le renommage en masse
sans casser les dépendances des outils aux noms dans la base OSM.
Et là, suite à la fantastique présentation de wikidata à Clermont, je
me dis et je vous transmets :
Si on mettais operator=wikidata:Q3587594 plutôt que Enedis ?
https://www.wikidata.org/wiki/Q3587594

Ça implique aux outils de représentation d'utiliser wikidata, et je
suis d'accord ça alourdi un peu le processus.
Mais sinon, ça simplifierai beaucoup de chose :-)

C'est dans la même veine que l'idée de Jean-Louis lors de sa
présentation : déplacer dans wikidata les histoires de liste de noms
alternatifs à rallonge. Wikidata est conçu pour ça, et on est vite
limité dans OSM avec nos quelques variantes de *_name et name_*.

C'est pas évident à mettre en place, mais je trouve cela très séduisant.



C'est très machine friendly mais par du tout human friendly... et pour 
l'instant les contributeurs sont plus des humain que des machines ;)


Ce qui pose plus problème c'est plutôt les clés que les valeurs... 
ref:RFF=* à remplacer à terme par ref:SNCF=* ?


--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2016-06-06 Par sujet Nicolas Dumoulin 
Salut,

Le Fri, 3 Jun 2016 19:28:51 +0200,
François Lacombe  a écrit :
> Quid de proposer au DWG de faire une migration en masse ?
> Plutôt facile à réaliser : overpass => query sur operator=ERDF => JSOM
> ctrl+A => operator=Enedis => Upload
> 
> Le principal enjeu est l'information de la communauté et la mise à
> jour des scripts de consommation.

Le cas se présente régulièrement : comment gérer le renommage en masse
sans casser les dépendances des outils aux noms dans la base OSM.
Et là, suite à la fantastique présentation de wikidata à Clermont, je
me dis et je vous transmets :
Si on mettais operator=wikidata:Q3587594 plutôt que Enedis ?
https://www.wikidata.org/wiki/Q3587594

Ça implique aux outils de représentation d'utiliser wikidata, et je
suis d'accord ça alourdi un peu le processus.
Mais sinon, ça simplifierai beaucoup de chose :-)

C'est dans la même veine que l'idée de Jean-Louis lors de sa
présentation : déplacer dans wikidata les histoires de liste de noms
alternatifs à rallonge. Wikidata est conçu pour ça, et on est vite
limité dans OSM avec nos quelques variantes de *_name et name_*.

C'est pas évident à mettre en place, mais je trouve cela très séduisant.

-- 
Nicolas Dumoulin


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2016-06-06 Par sujet Romain MEHUT 
Bonjour,

Il s'agit également de prendre en compte le libellé "Électricité Réseau
Distribution France" que j'ai écrit tel quel car vu ainsi sur le terrain...

Romain

Le 3 juin 2016 à 19:28, François Lacombe  a
écrit :

> Bonjour la liste,
>
> comme vous l'avez peut-être vu ces derniers jours, l'opérateur de
> distribution électrique ERDF a changé de nom pour Enedis.
> RFF l'a précédé en 2015 pour donner naissance à SNCF Réseau, pour ne
> citer qu'un cas probablement parmi tant d'autres avec la fusion des
> communes, fusion des régions, etc...
>
> Pourtant dans OSM :
> operator=RFF, 3349 objets
> operator=SNCF Réseau, 3205 objets
> operator=ERDF, 25768 objets
> operator=Enedis, 0 objets
>
> Comme on peut le voir, les objets attribués à RFF migrent
> difficilement vers la nouvelle valeur (si tant est que SNCF Réseau
> soit la valeur à appliquer. La confusion avec Gares & connexion est
> facile et il en va de même avec les autres filiales de la SNCF).
>
> Ça me semble être un problème, et nous avons tout intérêt à avoir un
> ensemble de données cohérentes.
> Il y a un ticket ouvert chez JOSM :
> https://josm.openstreetmap.de/ticket/12914
>
> J'ai déjà commencé à mettre à jour le wiki, mais cela ne suffira
> pourtant pas à obtenir un ensemble cohérent avant un certain nombre
> d'années.
>
> Quid de proposer au DWG de faire une migration en masse ?
> Plutôt facile à réaliser : overpass => query sur operator=ERDF => JSOM
> ctrl+A => operator=Enedis => Upload
>
> Le principal enjeu est l'information de la communauté et la mise à
> jour des scripts de consommation.
>
> A+
>
> François
>
> ___
> 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

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

2016-06-04 Par sujet osm . sanspourriel 

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


Le 04/06/2016 19:43, osm.sanspourr...@spamgourmet.com a écrit :

le 2016-06-04 à 19:18, DH - dhel...@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 
, 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 -

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

2016-06-04 Par sujet Jérôme Seigneuret 
> 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é

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

2016-06-04 Par sujet DH 

Le 04/06/2016 19:43, osm.sanspourr...@spamgourmet.com a écrit :

le 2016-06-04 à 19:18, DH - dhel...@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)
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
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.


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 
, 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.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2016-06-04 Par sujet osm . sanspourriel 

le 2016-06-04 à 19:18, DH - dhel...@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".
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 ;-(.
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. 
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.


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 
, 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.


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

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

2016-06-04 Par sujet DH 

Le 04/06/2016 16:24, Jérôme Seigneuret a écrit :



Le 03/06/2016 à 23:26, DH a écrit :

Justement l'idée c'est d'avoir, à terme, une super relation
"Réseau Ferré National" avec operator=SNCF Réseau (1), dedans
toutes les relations de lignes composées des relations de
voies, composées des tronçons, les relations de gares

Bœurk… Je suis le seul à trouver ça affreux ?
JB.

Non je suis aussi contre ce genre de pratique. Qu'il y ai une
super relation sur l'usage des voies commerciale peut se
comprendre mais c'est pas réservé au fait que l’opérateur soit
SNCF Réseau. En plus rien n'est dit que dans le temps (avec
l'ouverture à la conccurance) SNCF Réseau soit l'opérateur qui en
sera en charge... Mais bon ça c'est un autre débat.



Personne n'a, pour le moment, parlé de voies commerciales. 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.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2016-06-04 Par sujet DH 

Le 04/06/2016 11:17, Éric Gillet a écrit :
Le 4 juin 2016 à 05:48, JB > a écrit :


Le 03/06/2016 à 23:26, DH a écrit :

Justement l'idée c'est d'avoir, à terme, une super relation
"Réseau Ferré National" avec operator=SNCF Réseau (1), dedans
toutes les relations de lignes composées des relations de
voies, composées des tronçons, les relations de gares 


Bœurk… Je suis le seul à trouver ça affreux ?

Je suis aussi de cet avis. Les relations ne sont pas des catégories 
. 
Chaque élément (tronçons, gares, etc.) sont gérés individuellement et 
donc méritent un tag operator=*, un gauge=*, etc.
L'usage de relation permet de lier plusieurs éléments entre eux, comme 
un réseau de voie ferrées, un itinéraire ou autre.


Le RFN n'est pas un réseau de voies ferrés donc ? what else ?
Est-ce une bonne pratique de mettre systématiquement oneway=no sur toute 
la voirie standard ?
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".
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2016-06-04 Par sujet Jérôme Seigneuret 
Le 03/06/2016 à 23:26, DH a écrit :
>
>> Justement l'idée c'est d'avoir, à terme, une super relation "Réseau Ferré
>> National" avec operator=SNCF Réseau (1), dedans toutes les relations de
>> lignes composées des relations de voies, composées des tronçons, les
>> relations de gares
>>
> Bœurk… Je suis le seul à trouver ça affreux ?
> JB.
>
> Non je suis aussi contre ce genre de pratique. Qu'il y ai une super
> relation sur l'usage des voies commerciale peut se comprendre mais c'est
> pas réservé au fait que l’opérateur soit SNCF Réseau. En plus rien n'est
> dit que dans le temps (avec l'ouverture à la conccurance) SNCF Réseau soit
> l'opérateur qui en sera en charge... Mais bon ça c'est un autre débat.
>

Le route_master ne doit servir qu'a regrouper des portions d'itinéraire
plus petit ou de direction différentes (forward, backward et variante(s) si
elle(s) existe(nt))

En clair il regroupe des relations existantes et apporte un nom global sur
cet ensemble. C'est ce que l'on retrouve pour le véloroute, les bus et
autres itinéraires qui se composent d'itinéraires plus simples dont le
niveau de relation est inférieur.

Si l'on prend La Poste, il n'y a pas une super-relation pour regrouper
l'ensemble des boîtes que l'opérateur doit gérer. Là c'est le même principe
qui s'applique.


*En particulier dans l'exemple du réseau alsacien, je vois plein de
tronçons nommés "Ligne de Strasbourg-Ville à Saint-Dié".A minima je
m'attendrais à ce que là ce soit une relation qui porte ref="110 000"*

Oui et non. C'est pas un itinéraire mais une ligne. C'est bien un
regroupement de voies partant d'une gare à une autre. Donc elle a un nom
partant d'une gare A à B avec de potentielles gares intermédiaires)

Vu que l'itinéraire n'est pas le réseau mais l’exploite, l'opérateur dans
la relation sera SNCF Voyageurs, Fret SNCF, BD... et les informations
contenu par la relation pourront être différentes avec des variantes
(passage ou non par des gares intérmédiaires)
Les voies (et donc les lignes) sont gérées par l'épic SNCF Réseau. C'est
donc bien sur le linéaire qu'est l'information.

*Sinon pourquoi ne pas supprimer les noms des rues de la Mairie pour mettre
toutes les rues de la Mairie dans une relation "rue de la Mairie" ;-) ?*

On ne le fait pas car il n'y a pas de relation pour regrouper des voies
routières (sauf type=multipolygon) le cas de regroupement est basé sur
l'existance d'adresses postal et donc la création d'une relation
* associatedStreet*
Même pour les cours d'eau c'est pas possible. Car il y a un nom pour
l'affluent mais celui-ci peut changer de nom sur le tronçon en partant de
sa source vers son exutoire.

Pour le coté énergie électrique c'est assez simple aussi. On nous dit que
ERDF devient Enedis. La raison est simple: confusion avec EDF ...
Donc le gestionnaire du réseau que les plaques aient changé ou non est
Enedis. C'est un gestionnaire à 95% du parc Français. Il reste donc des
opérateurs différents ce qui est le cas sur certains barrages
hydrau-électriques comme la SHEM et la CNR (c'est aussi le cas des autres
énergies renouvelables)

EDF gère quoi? Ben rien à ce niveau car c'est la filiale Enedis qui se
charge du travail. Au même titre que c'est plus Engie (GDF) mais GRDF qui
s'occupe de la maintenance pour le gaz avec une obligation de neutralité.

EDF, Engie, SNCF sont des groupes dont la partie gestion et distribution a
été sortie pour des raisons de neutralité lors de l'ouverture à la
concurrence imposée par l'Europe. D'où les Epic Enedis, GRDF et SNCF Réseau

Bon week-end
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2016-06-04 Par sujet Éric Gillet 
Le 4 juin 2016 à 05:48, JB  a écrit :

> Le 03/06/2016 à 23:26, DH a écrit :
>
>> Justement l'idée c'est d'avoir, à terme, une super relation "Réseau Ferré
>> National" avec operator=SNCF Réseau (1), dedans toutes les relations de
>> lignes composées des relations de voies, composées des tronçons, les
>> relations de gares
>
> Bœurk… Je suis le seul à trouver ça affreux ?


Je suis aussi de cet avis. Les relations ne sont pas des catégories
.
Chaque élément (tronçons, gares, etc.) sont gérés individuellement et donc
méritent un tag operator=*, un gauge=*, etc.
L'usage de relation permet de lier plusieurs éléments entre eux, comme un
réseau de voie ferrées, un itinéraire ou autre.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2016-06-03 Par sujet Philippe Verdy 
Peut-être que certains gros clients indistriels gèrent eux-mêmes les postes
de distribution sur leurs sites (et tout le filaire aval), et se branchent
alors ailleurs en amont sur d'autres réseaux de distribution: c'est
peut-être EDF qui les a construits à l'origine, ERDF n'a sans doute même
jamais été concerné par ces postes si la cession a eu lieu avant.


Le 4 juin 2016 à 00:42,  a écrit :

>
>
> Le 2016-06-03 à 22:53, François Lacombe - fl.infosrese...@gmail.com a
> écrit :
>
> Mais quand le terrain va plus vite que les corrections, il faut changer de
> braquet.
>
> +1 et il vaut mieux tout faire d'un coup quand c'est simple plutôt
> qu'attendre que la communauté commence et qu'on arrive à une situation
> mixte (ERDF+Enedis).
> Au fait Enedis comme énergie distribution, ils comptent se diversifier ?
> Acheter GRDF ???
>
> Sur les arrêts : tu mets quoi comme opérateur ? Celui qui gère l'abribus
> (Decaux?) ou la compagnie de bus (une filiale de Keolis probablement) ?
> Effectivement j'aurais tendance à ne pas mettre d'opérateur pour un
> abribus.
> Par contre pour un transfo (power=substation) je ne veux pas récupérer les
> 85 % du réseau BT français pour voir qu'il est concédé à Enedis (relation
> qui n'existe d'ailleurs pas... encore).
>
> http://mc.bbbike.org/mc/?lon=-3.413426=47.745501=18=2=osmfr=mapbox-hybrid=building:yes%3Cbr%3Eoperator:EDF%3Cbr%3Epower:substation%3Cbr%3Eref:MLTVULCA
>
> C'est étrange cet objet, parce que dans cette zone en particulier il y
> a l'utilisateur Libre à Quimperlé qui pousse des infos exhaustives sur
> ces posteshttps://www.openstreetmap.org/way/89855678#map=19/47.86499/-3.54835
>
> La ref MLTVULCA correspond à quoi ?
> Ca pourrait être une régie locale ?
>
> non, c'est le "nom" du poste (le "texte" affiché sur le poste), c'est
> d'ailleurs Libre à Quimperlé qui a entré la version initiale (et la ref
> comme name).
>
> Maintenant je connais un transformateur qui n'appartient pas à ERDF mais qui
> est un poste client marqué EDF si je n'abuse (mais qui n'appartient pas à
> EDF et n'est pas opéré par EDF non plus).
>
> On peut voir ?
>
> François
>
> Pas encore sous OSM, je ferai une photo à l'occasion.
>
> 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

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

2016-06-03 Par sujet osm . sanspourriel 



Le 2016-06-03 à 22:53, François Lacombe - fl.infosrese...@gmail.com a 
écrit :
Mais quand le terrain va plus vite que les corrections, il faut 
changer de braquet.
+1 et il vaut mieux tout faire d'un coup quand c'est simple plutôt 
qu'attendre que la communauté commence et qu'on arrive à une situation 
mixte (ERDF+Enedis).
Au fait Enedis comme énergie distribution, ils comptent se diversifier ? 
Acheter GRDF ???


Sur les arrêts : tu mets quoi comme opérateur ? Celui qui gère l'abribus 
(Decaux?) ou la compagnie de bus (une filiale de Keolis probablement) ?

Effectivement j'aurais tendance à ne pas mettre d'opérateur pour un abribus.
Par contre pour un transfo (power=substation) je ne veux pas récupérer 
les 85 % du réseau BT français pour voir qu'il est concédé à Enedis 
(relation qui n'existe d'ailleurs pas... encore).

http://mc.bbbike.org/mc/?lon=-3.413426=47.745501=18=2=osmfr=mapbox-hybrid=building:yes%3Cbr%3Eoperator:EDF%3Cbr%3Epower:substation%3Cbr%3Eref:MLTVULCA

C'est étrange cet objet, parce que dans cette zone en particulier il y
a l'utilisateur Libre à Quimperlé qui pousse des infos exhaustives sur
ces postes
https://www.openstreetmap.org/way/89855678#map=19/47.86499/-3.54835

La ref MLTVULCA correspond à quoi ?
Ca pourrait être une régie locale ?
non, c'est le "nom" du poste (le "texte" affiché sur le poste), c'est 
d'ailleurs Libre à Quimperlé qui a entré la version initiale (et la ref 
comme name).

Maintenant je connais un transformateur qui n'appartient pas à ERDF mais qui
est un poste client marqué EDF si je n'abuse (mais qui n'appartient pas à
EDF et n'est pas opéré par EDF non plus).
On peut voir ?

François

Pas encore sous OSM, je ferai une photo à l'occasion.

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

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

2016-06-03 Par sujet Éric Gillet 
Je suis 100% pour l'uniformisation des operator !

Le 3 juin 2016 à 19:28, François Lacombe  a
écrit :

> Bonjour la liste,
>
> comme vous l'avez peut-être vu ces derniers jours, l'opérateur de
> distribution électrique ERDF a changé de nom pour Enedis.
> RFF l'a précédé en 2015 pour donner naissance à SNCF Réseau, pour ne
> citer qu'un cas probablement parmi tant d'autres avec la fusion des
> communes, fusion des régions, etc...
>
> Pourtant dans OSM :
> operator=RFF, 3349 objets
> operator=SNCF Réseau, 3205 objets
> operator=ERDF, 25768 objets
> operator=Enedis, 0 objets
>
> Comme on peut le voir, les objets attribués à RFF migrent
> difficilement vers la nouvelle valeur (si tant est que SNCF Réseau
> soit la valeur à appliquer. La confusion avec Gares & connexion est
> facile et il en va de même avec les autres filiales de la SNCF).
>
> Ça me semble être un problème, et nous avons tout intérêt à avoir un
> ensemble de données cohérentes.
> Il y a un ticket ouvert chez JOSM :
> https://josm.openstreetmap.de/ticket/12914
>
> J'ai déjà commencé à mettre à jour le wiki, mais cela ne suffira
> pourtant pas à obtenir un ensemble cohérent avant un certain nombre
> d'années.
>
> Quid de proposer au DWG de faire une migration en masse ?
> Plutôt facile à réaliser : overpass => query sur operator=ERDF => JSOM
> ctrl+A => operator=Enedis => Upload
>
> Le principal enjeu est l'information de la communauté et la mise à
> jour des scripts de consommation.
>
> A+
>
> François
>
> ___
> 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

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

2016-06-03 Par sujet DH 

Le 03/06/2016 22:53, François Lacombe a écrit :

Bonsoir Denis

Le 3 juin 2016 à 21:20, DH  a écrit :

Pour les RFF, je les dégomme dès que j'en vois façon
http://www.toupty.com/jeuasteroids.html (ça ne nous rajeunit pas ;-)
note : tagger operator pour chaque tronçon ferroviaire n'est pas l'idée la
plus productive. La relation c'est bien pour cela ; les relations, c'est
bien (point).

C'est bien ce qui est de mise la plupart du temps, à chaque fois qu'on
vois une "erreur", on la corrige.
Mais quand le terrain va plus vite que les corrections, il faut
changer de braquet. Sinon on va revenir sans cesse sur les mêmes
choses.

Pareil dans les transports : quand un opérateur de réseau change en
ville, question de main d’œuvre, mais attendre que tout les arrêts
soient visités... c'est long.

Sur le point de vue de la relation, pourquoi pas
Ça oblige cependant à visiter toutes les relations dont fait partie un
objet donné pour avoir l'info :)


Justement l'idée c'est d'avoir, à terme, une super relation "Réseau 
Ferré National" avec operator=SNCF Réseau (1), dedans toutes les 
relations de lignes composées des relations de voies, composées des 
tronçons, les relations de gares (quoique ça va être rapidement le 
bordel entre RATP, Gare & Connexion et Réseau suivant le contenu de la 
relation), etc.
A chaque niveau ses particularités propres. Cela n'a pas de sens de 
mettre un gauge=1435 ou electrified=no sur le moindre tronçon qui 
appartient à un ensemble homogène. Après il y a les should et les must.
Je comprend que la majorité des contributeurs n'est pas forcément à 
l'aise avec les relations ; il y a un long travail de pédagogie à faire 
et d'initialisation (peur de la page blanche)
Je découvre peu à peu l'ampleur de la diversité des pratiques de matière 
de cartographie ferroviaire. C'est formateur pour écrire de la doc (de 
l'ad hoc et pas de l'haddock).


1. je commence par les versions territoriales (enfin la plus proche ;-): 
http://www.openstreetmap.org/relation/6250218


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2016-06-03 Par sujet François Lacombe 
Bonsoir Denis

Le 3 juin 2016 à 21:20, DH  a écrit :
>
> Pour les RFF, je les dégomme dès que j'en vois façon
> http://www.toupty.com/jeuasteroids.html (ça ne nous rajeunit pas ;-)
> note : tagger operator pour chaque tronçon ferroviaire n'est pas l'idée la
> plus productive. La relation c'est bien pour cela ; les relations, c'est
> bien (point).

C'est bien ce qui est de mise la plupart du temps, à chaque fois qu'on
vois une "erreur", on la corrige.
Mais quand le terrain va plus vite que les corrections, il faut
changer de braquet. Sinon on va revenir sans cesse sur les mêmes
choses.

Pareil dans les transports : quand un opérateur de réseau change en
ville, question de main d’œuvre, mais attendre que tout les arrêts
soient visités... c'est long.

Sur le point de vue de la relation, pourquoi pas
Ça oblige cependant à visiter toutes les relations dont fait partie un
objet donné pour avoir l'info :)


Le 3 juin 2016 à 21:48,   a écrit :
>
> Ce sont bien des transformateurs HTA (building=yes + power=substation) avec
> operator=EDF. Ceux-ci ne devraient pas, sauf erreur ou exception, être
> attribués à EDF.
>
> Or il y en a 1484+345=1829 objets ainsi décrits
> http://overpass-turbo.eu/s/gC1
>
> Ceux avec operator=ERDF sont au nombre de 4935+114=5049, soit 27 % de
> mauvais operator (OK, 100% depuis le 1er juin).

Ok c'est ca :)

Il y a aussi les poteaux, les lignes, les postes sources, les
isolateurs, les portiques
http://overpass-turbo.eu/s/gC8

>
> http://mc.bbbike.org/mc/?lon=-3.413426=47.745501=18=2=osmfr=mapbox-hybrid=building:yes%3Cbr%3Eoperator:EDF%3Cbr%3Epower:substation%3Cbr%3Eref:MLTVULCA

C'est étrange cet objet, parce que dans cette zone en particulier il y
a l'utilisateur Libre à Quimperlé qui pousse des infos exhaustives sur
ces postes
https://www.openstreetmap.org/way/89855678#map=19/47.86499/-3.54835

La ref MLTVULCA correspond à quoi ?
Ca pourrait être une régie locale ?

>
> Maintenant je connais un transformateur qui n'appartient pas à ERDF mais qui
> est un poste client marqué EDF si je n'abuse (mais qui n'appartient pas à
> EDF et n'est pas opéré par EDF non plus).

On peut voir ?

François

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2016-06-03 Par sujet osm . sanspourriel 

Bonjour François,

Ma mise en garde va dans le même sens que la tienne.

http://mc.bbbike.org/mc/?lon=-3.413426=47.745501=18=2=osmfr=mapbox-hybrid=building:yes%3Cbr%3Eoperator:EDF%3Cbr%3Epower:substation%3Cbr%3Eref:MLTVULCA

Ce sont bien des transformateurs HTA (building=yes + power=substation) 
avec operator=EDF. Ceux-ci ne devraient pas, sauf erreur ou exception, 
être attribués à EDF.


Or il y en a 1484+345=1829 objets ainsi décrits 
http://overpass-turbo.eu/s/gC1


Ceux avec operator=ERDF sont au nombre de 4935+114=5049, soit 27 % de 
mauvais operator (OK, 100% depuis le 1er juin).


Maintenant je connais un transformateur qui n'appartient pas à ERDF mais 
qui est un poste client marqué EDF si je n'abuse (mais qui n'appartient 
pas à EDF et n'est pas opéré par EDF non plus).


Jean-Yvon

Le 2016-06-03 à 20:35, François Lacombe - fl.infosrese...@gmail.com a 
écrit :

Bonjour Jean-Yvon,

Le 3 juin 2016 à 20:25,   a écrit :

sans compter les transformateurs souvent attribués par erreur à EDF. Et là
le changement massif est sans doute plus douteux.

operator=EDF ne doit être attribué qu'aux équipements (centrales,
générateurs) de production, puisque c'est la seule activité de la
maison mère.

Qu'entends-tu exactement par transformateur ?
Pour moi c'est un appareil, pas un bâtiment alors qu'on trouve souvent
des building=yes + power=transformer au lieu de building=yes +
power=substation.

Il est question de ce genre de chose
http://www.infos-reseaux.com/photos/image/122-poste-de-transformation-hta

cf http://wiki.openstreetmap.org/wiki/FR:Tag:power%3Dtransformer

Attention je ne parlais pas de toucher à operator=EDF, mais uniquement
à operator=ERDF
Pour operator=EDF c'est un travail de longue haleine, puisqu'on ne
sait pas effectivement si c'est de l'EDF, du RTE, de l'Enedis,... sauf
à avoir un objet plus détaillé.



Car si la CRE a demandé à ERDF de changer de nom pour ne plus avoir de
confusion avec sa maison mère à 100% EDF SA, les transformateurs sont encore
marqués de l'ancien nom EDF du temps ou cette entreprise était un service
public.

Les transformateurs en eux-même sont rarement marqué du logo d'EDF
mais plutôt du fabriquant (transfix, cahors,...)
http://www.infos-reseaux.com/photos/image.php?id=48

Par contre sur les postes de transformation (bâtiment), il y a des
plaquettes qui donnent parfois le nom de l'exploitant.
http://wiki.openstreetmap.org/wiki/File:French_substation_id.jpg
C'est un faux ami : comme les plaques en fonte sur le trottoir, les
fournisseurs ont des moules et on utilise le matériel le plus courant.
Même les postes des régies locales peuvent avoir des choses de ce style.



Pour GRDF, c'est la maison mère qui a changé de nom (Engie).

Operator : y a-t-il des boîtes-aux-lettres de rue en France qui se sont pas
de FR:LaPoste ? Sinon pourquoi ne pas faire de même ?

Je regarderais du côté de Mediapost, Adrexxo,...


A+

François

___
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

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

2016-06-03 Par sujet DH 

Le 03/06/2016 19:28, François Lacombe a écrit :

Bonjour la liste,

comme vous l'avez peut-être vu ces derniers jours, l'opérateur de
distribution électrique ERDF a changé de nom pour Enedis.
RFF l'a précédé en 2015 pour donner naissance à SNCF Réseau, pour ne
citer qu'un cas probablement parmi tant d'autres avec la fusion des
communes, fusion des régions, etc...

Pourtant dans OSM :
operator=RFF, 3349 objets
operator=SNCF Réseau, 3205 objets
operator=ERDF, 25768 objets
operator=Enedis, 0 objets




Pour les RFF, je les dégomme dès que j'en vois façon 
http://www.toupty.com/jeuasteroids.html (ça ne nous rajeunit pas ;-)
note : tagger operator pour chaque tronçon ferroviaire n'est pas l'idée 
la plus productive. La relation c'est bien pour cela ; les relations, 
c'est bien (point).


Denis


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2016-06-03 Par sujet François Lacombe 
Bonjour Jean-Yvon,

Le 3 juin 2016 à 20:25,   a écrit :
> sans compter les transformateurs souvent attribués par erreur à EDF. Et là
> le changement massif est sans doute plus douteux.

operator=EDF ne doit être attribué qu'aux équipements (centrales,
générateurs) de production, puisque c'est la seule activité de la
maison mère.

Qu'entends-tu exactement par transformateur ?
Pour moi c'est un appareil, pas un bâtiment alors qu'on trouve souvent
des building=yes + power=transformer au lieu de building=yes +
power=substation.

Il est question de ce genre de chose
http://www.infos-reseaux.com/photos/image/122-poste-de-transformation-hta

cf http://wiki.openstreetmap.org/wiki/FR:Tag:power%3Dtransformer

Attention je ne parlais pas de toucher à operator=EDF, mais uniquement
à operator=ERDF
Pour operator=EDF c'est un travail de longue haleine, puisqu'on ne
sait pas effectivement si c'est de l'EDF, du RTE, de l'Enedis,... sauf
à avoir un objet plus détaillé.


>
> Car si la CRE a demandé à ERDF de changer de nom pour ne plus avoir de
> confusion avec sa maison mère à 100% EDF SA, les transformateurs sont encore
> marqués de l'ancien nom EDF du temps ou cette entreprise était un service
> public.
Les transformateurs en eux-même sont rarement marqué du logo d'EDF
mais plutôt du fabriquant (transfix, cahors,...)
http://www.infos-reseaux.com/photos/image.php?id=48

Par contre sur les postes de transformation (bâtiment), il y a des
plaquettes qui donnent parfois le nom de l'exploitant.
http://wiki.openstreetmap.org/wiki/File:French_substation_id.jpg
C'est un faux ami : comme les plaques en fonte sur le trottoir, les
fournisseurs ont des moules et on utilise le matériel le plus courant.
Même les postes des régies locales peuvent avoir des choses de ce style.


> Pour GRDF, c'est la maison mère qui a changé de nom (Engie).
>
> Operator : y a-t-il des boîtes-aux-lettres de rue en France qui se sont pas
> de FR:LaPoste ? Sinon pourquoi ne pas faire de même ?

Je regarderais du côté de Mediapost, Adrexxo,...


A+

François

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2016-06-03 Par sujet osm . sanspourriel 
sans compter les transformateurs souvent attribués par erreur à EDF. Et 
là le changement massif est sans doute plus douteux.


Car si la CRE a demandé à ERDF de changer de nom pour ne plus avoir de 
confusion avec sa maison mère à 100% EDF SA, les transformateurs sont 
encore marqués de l'ancien nom EDF du temps ou cette entreprise était un 
service public.


Pour GRDF, c'est la maison mère qui a changé de nom (Engie).

Operator : y a-t-il des boîtes-aux-lettres de rue en France qui se sont 
pas de FR:LaPoste ? Sinon pourquoi ne pas faire de même ?


Jean-Yvon

Le 2016-06-03 à 19:28, François Lacombe - fl.infosrese...@gmail.com a 
écrit :

Bonjour la liste,

comme vous l'avez peut-être vu ces derniers jours, l'opérateur de
distribution électrique ERDF a changé de nom pour Enedis.
RFF l'a précédé en 2015 pour donner naissance à SNCF Réseau, pour ne
citer qu'un cas probablement parmi tant d'autres avec la fusion des
communes, fusion des régions, etc...

Pourtant dans OSM :
operator=RFF, 3349 objets
operator=SNCF Réseau, 3205 objets
operator=ERDF, 25768 objets
operator=Enedis, 0 objets

Comme on peut le voir, les objets attribués à RFF migrent
difficilement vers la nouvelle valeur (si tant est que SNCF Réseau
soit la valeur à appliquer. La confusion avec Gares & connexion est
facile et il en va de même avec les autres filiales de la SNCF).

Ça me semble être un problème, et nous avons tout intérêt à avoir un
ensemble de données cohérentes.
Il y a un ticket ouvert chez JOSM : https://josm.openstreetmap.de/ticket/12914

J'ai déjà commencé à mettre à jour le wiki, mais cela ne suffira
pourtant pas à obtenir un ensemble cohérent avant un certain nombre
d'années.

Quid de proposer au DWG de faire une migration en masse ?
Plutôt facile à réaliser : overpass => query sur operator=ERDF => JSOM
ctrl+A => operator=Enedis => Upload

Le principal enjeu est l'information de la communauté et la mise à
jour des scripts de consommation.

A+

François

___
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

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

2016-06-03 Par sujet François Lacombe 
Bonjour la liste,

comme vous l'avez peut-être vu ces derniers jours, l'opérateur de
distribution électrique ERDF a changé de nom pour Enedis.
RFF l'a précédé en 2015 pour donner naissance à SNCF Réseau, pour ne
citer qu'un cas probablement parmi tant d'autres avec la fusion des
communes, fusion des régions, etc...

Pourtant dans OSM :
operator=RFF, 3349 objets
operator=SNCF Réseau, 3205 objets
operator=ERDF, 25768 objets
operator=Enedis, 0 objets

Comme on peut le voir, les objets attribués à RFF migrent
difficilement vers la nouvelle valeur (si tant est que SNCF Réseau
soit la valeur à appliquer. La confusion avec Gares & connexion est
facile et il en va de même avec les autres filiales de la SNCF).

Ça me semble être un problème, et nous avons tout intérêt à avoir un
ensemble de données cohérentes.
Il y a un ticket ouvert chez JOSM : https://josm.openstreetmap.de/ticket/12914

J'ai déjà commencé à mettre à jour le wiki, mais cela ne suffira
pourtant pas à obtenir un ensemble cohérent avant un certain nombre
d'années.

Quid de proposer au DWG de faire une migration en masse ?
Plutôt facile à réaliser : overpass => query sur operator=ERDF => JSOM
ctrl+A => operator=Enedis => Upload

Le principal enjeu est l'information de la communauté et la mise à
jour des scripts de consommation.

A+

François

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr