Re: [OSM-talk-fr] Références nationales : RNA

[François Lacombe]

Le lun. 10 juin 2019 à 16:22, deuzeffe  a écrit :

>
> Ajouter ref type RNA à un POI clairement identifié comme étant le lieu
> *d'activités* d'une assoc. Et il y en a par chez moi, c'est bien pour ça
> que je m'y suis intéressée. Et je peux t'assurer qu'ils ont une réalité
> physique.
>

Oui en fait c'est pareil qu'une enseigne de magasin remarque, on ne fait
pas une relation des magasins qui partagent la même enseigne.
Quoi que l'enseigne se voit et le RNA un peu moins mais c'est un problème
de source, chaque asso pourrait bien coller son RNA sur la porte si elle le
voulait.
Je n'ai rien dit

En revanche si on met le RNA, il faut aussi mettre le SIRET (à minima le
SIREN) et pas que des associations
Je parlais bien de tous les SIRET, pas que ceux ds assos.

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

Re: [OSM-talk-fr] Références nationales : RNA

[François Lacombe]

Le lun. 10 juin 2019 à 16:48, deuzeffe  a écrit :

> Je prendrais une autre comparaison, avec les communes, par ex. : pour
> moi, le RNA est l'équivalent du n°INSEE de la commune (la plupart du
> temps complètement inconnu de la population générale), le nom de l'asso.
> apposé sur son local est l'équivalent du panneau d'entrée d'agglomération.
>

C'est bien ça oui

Est-ce que le n° INSEE de la commune est présent sur le/les panneaux
> d'entrée d'agglo. ?
>

Non mais les communes pourraient l'afficher si elles le voulaient, c'était
ce que je voulais dire.

C'est pas parce que ton domaine de compétences affiche fièrement ses
> réf. au vu et au su du public que tous les autres font pareil ;p
>

Pas toujours et même quand c'est affiché il serait bien d'avoir des données
officielles pour vérifier que c'est bien cohérent

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

Re: [OSM-talk-fr] Nom de poste source haute-tension ?

[François Lacombe]

Bonjour Yves,

Une réponse rapide en attendant celle aux questions sur les gazoducs

En effet les postes sources sont bien propriété et exploitation Enedis (ou
ELD ce cas échéant)
Donc :
ref:FR:RTE=MTREV
ref:FR:RTE_nom=MONTREVEL
name=Montrevel PCCN (j'ai tendance à mettre "Poste source de Montrevel,
mais l'affichage terrain prime)
operator=Enedis
substation=distribution
voltage=63000


A bientôt

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

Re: [OSM-talk-fr] éoliennes

[François Lacombe]

Hello

Le ven. 21 juin 2019 à 20:48,  a écrit :

> Bonjour,
>
> Si vraiment ça lui pose problème que ce soit un way, alors il doit juste
> enlever les attributs relatifs à power mais laisser le bâti et ajouter un
> nœud au centre du bâti.
>
Effectivement, tout est possible
Différencier le mat du générateur est un luxe, mais plus proche de la
réalité : le mat supporte le générateur situé dans la nacelle.

Quoi qu'il en soit, perdre des attributs suite à ces modifs est dommage,
qui plus est en cassant des relations.
Je confirme que la plupart des parc éoliens sont documentés avec des
relations : il n'y a pas de clôture et des agriculteurs continuent
d'exploiter les terres au milieu.

Ways, nodes ou les deux ne change rien d'un point de vue industriel, je
laisse les autres compléter

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

Re: [OSM-talk-fr] Références nationales : RNA

[François Lacombe]

Salut à tous,

Je débarque un peu, mais quelle existence physique représente le RNA ?
Si on ajoute ces références, il faut également ajouter les SIRET.
Or tous ces identifiants sont ceux d'établissements qui n'ont pas de
réalité physique.

Si il fallait documenter les organisations des entreprises/assocs, il
faudrait faire des relations impliquant tous les sites en question.
Le but de ref: est bien de porter des références le plus possible uniques,
sinon on reproduit des relations déguisées

Qu'en pensez-vous?

François

Le lun. 10 juin 2019 à 15:15, deuzeffe  a écrit :

> On 10/06/2019 15:06, Magalie Dartus wrote:
> > Bonjour,
>
> De même,
>
> > On ne peut donc pas se baser sur les SIRET pour avoir une information
> > exhaustive sur les assos.
>
> Merci pour la précision. Et ce n'est pas le but. C'est plutôt une alerte
> : "Si vous mappez un local d'assoc. regardez s'il n'y a pas RNA, SIRET
> et SIREN à ajouter".
>
> --
> deuzeffe
>
> ___
> 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] Nom de poste source haute-tension ?

[François Lacombe]

Bonsoir George,

Le mar. 11 juin 2019 à 21:06, George Kaplan  a
écrit :

> Ce n’est pas toujours vrai. Il existe environ 300 postes sur les 2200 qui
> sont sous exploitation RTE. Pour la propriété, on retrouve des variations
> entre qui possède le terrain, qui l’enceinte, qui les bâtiments, bien que
> les zones d’intervention de chaque intervenant soient clairement définies.
>
Je dois être d'accord avec toi, mais pour être sur, parles-tu bien de
postes comme celui-ci :  https://www.openstreetmap.org/way/100500802 ?
Dans ce cas c'est RTE qui l'emporte, parce qu'il ne doit y avoir qu'une
seule valeur de operator sur le poste (l'enceinte dirais-je, le matériel à
l'intérieur c'est différent)

Pour la compréhension de ce point, il faut considérer 3 limites :
propriété, exploitation et conduite
Il y a des cas où elles sont différentes, et sur le terrain on ne verra que
l'exploitation (qui intervient sur le matériel lors de travaux)

A noter qu'un concepteur a eu l'idée géniale de différencier la couleur des
agrégats de finition sur les postes partagés les plus récents : noir c'est
RTE, blanc c'est le client (Enedis... SNCF...)
Ici par exemple à la sous-station 400kV/25kV de la LGV SEA à Clérac
https://www.geoportail.gouv.fr/carte?c=-0.2508332203417089,45.17802722768411=18=ORTHOIMAGERY.ORTHOPHOTOS::GEOPORTAIL:OGC:WMTS(1)=yes
Ainsi on comprends bien que les départs et les barres 400kV sont en
exploitation et propriété RTE, le reste à la SNCF.
Ca va se généraliser au gré des travaux, on est pas prêt d'avoir tout le
réseau comme ça, mais on progresse.

Dans l'attente, il y a cette doc-ci qu'il faudrait que je complète
https://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/France#Attribution_de_l.27op.C3.A9rateur

Bonne soirée

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

[OSM-talk-fr] Proposition - RFC - Les points de distribution télécoms

[François Lacombe]

Salut à tous,

Suite à la proposition votée l'année dernières sur les réseaux télécoms, un
besoin non couvert est apparu dernièrement.
Cette proposition fourni un moyen cohérent de décrire les points de
distribution télécoms
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Telecom_distribution_points

C'est comme à mon habitude un sujet très particulier, mais il y a plusieurs
millions de ces boitiers en France, quantité en croissance avec le
déploiement des réseaux en fibre optique.
Ainsi quelqu'un sera tôt ou tard tenté de les ajouter dans la base, autant
que ce soit fait avec une description cohérente et documentée.

Il y a pour l'instant que des exemples français, je suis à la recherche
d'illustrations internationales pour faire voter quelque chose qui parle à
plus de monde. C'est pour l'instant un RFC.
N’hésitez pas à contribuer si vous vous le pouvez

Bonne soirée

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

Re: [OSM-talk-fr] Postes de transformations électrique de "quartier" (sous-stations)

[François Lacombe]

Bonsoir Yves

Le lun. 29 avr. 2019 à 12:02, Yves P.  a écrit :

> Bonjour,
>
> Suite au message précédent de François souhaitant découper sa proposition
> d’origine, je souhaitais montrer la « complexité » actuelle pour rechercher
> des « transformateurs » pour le contributeur lambda.
>

Pour les non initiés, il s'agit de ce brouillon (en cours d'écriture) :
https://wiki.openstreetmap.org/wiki/Proposed_features/Substation_nodes_extension


> Un « transfo » sur poteau
>  (type H61 en
> France) est un « transfo » comme un autre (en armoire, cabine haute, cabine
> basse…) ?
> Et bien non ! Du moins pour certains logiciels que j’utilise à la maison
> ou sur le terrain :
>

Parce qu'il n'y a pas eu de mise en commun, c'est le but de cette
proposition à venir.
Sur le terrain c'est marqué "POSTE" donc on va retrouver un
power=substation partout, même sur les poteaux avec un transformateur.
Ce sera plus cohérent avec ce que tout le monde observe sur le terrain.


> En espérant que la future proposition de François sur le sujet sera
> acceptée.
>

Il faut déjà finir de l'écrire :)

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

Re: [OSM-talk-fr] éditeur ID

[François Lacombe]

Bonsoir Jean-Yvon

Je partage ton constat, ils affichent bien leur position de ne pas prendre
en compte le wiki.
Ici encore dans cet échange où je leur suggérait de s'apuyer sur les Data
Items (récent ajout qui implément wikidata pour les tags sur le wiki)
https://github.com/openstreetmap/iD/issues/6206

"Sorry, but I'm really not interested in adding anything wiki as a critical
dependency on how iD works."

Certes le wiki n'a pas réponse à tout et manque parfois de fraicheur, mais
tout de même
Le problème c'est que iD rend aussi beaucoup de services et offre un
éditeur de qualité accessible et didactique. On ne peut pas lui enlever
Ce n'est pas une raison pour tout accepter

Issue ouverte pour location=kiosk
https://github.com/openstreetmap/iD/issues/6283

Bonne soirée

François

Le mer. 1 mai 2019 à 19:36,  a écrit :

> Récemment HebdOSM signalait que Frederik protestait contre la manière
> d'agir des deux développeurs d'ID.
>
> Développeurs d'un des deux principaux éditeurs d'OSM mais qui fonctionnent
> au doigt mouillé sans tenir compte des listes de discussion ou du Wiki.
>
> Dernièrement je suis tombé sur une intersection entre un ruisseau et une
> route correctement signalée par Osmose.
>
> J'édite la route. ID me propose de mettre un nœud simple_brunnel.
>
> Effectivement ça ne mérite pas plus.
>
> Sauf que maintenant Osmose râle car bridge ne doit pas être utilisé sur
> les points comme l'indique le Wiki
> .
>
> En cherchant j'ai trouvé une proposition datant de 2014 et a priori jamais
> passée par un vote :
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Simple_one_node_culvert_or_bridge
>
> Je pourrais entrer un ticket pour signaler le problème côté Osmose. Sauf
> que c'est ID qui ne respecte pas la communauté, pas Osmose.
>
> Dans ce cas précis, proposer un vote pourrait donner une légitimité pour
> un tag qui a été utilisé essentiellement en 2014-2015 (date de la
> proposition) et surtout en Autriche .
>
> 2008 1
> 2013 1
> 2014 153
> 2015 250
> 2016 33
> 2017 85
> 2018 25
> 2019 13
>
>
> Autre problèmes rencontrés avec ID, liste non exhaustive ça va de soi :
>
> - sur associatedStreet il propose address alors que le wiki dit de
> privilégier housenumber (et par défaut ne propose pas non plus de relation
> de type associatedStreet)
>
> - sur bus stop/platform il propose network allors qu'Osmose dit de ne pas
> utiliser network sur ces objets.
>
> - il propose location=kiosk alors que cette valeur est dépréciée
>
> - sur d'autres objets il va proposer aussi bien choix_numéro_1 que
> choix-numéro-1 et le débutant va choisir au petit bonheur.
>
> Comme vous le voyiez beaucoup des problèmes vient du fait que les deux
> développeurs payés ne tiennent pas compte de la communauté. Avec le risque
> que ce soit les visions des entreprise pour lesquelles travaillent les deux
> développeurs qui décident de l'avenir d'OSM.
>
> Un point à aborder lors du SotM monde à Heidelberg ?
>
> 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] polygone pour représenter un trottoir

[François Lacombe]

Hello

Le sam. 27 avr. 2019 à 18:48,  a écrit :

> on parle de polygone (way fermé avec area=yes) pas de multi-polygone : un
> trottoir c'est continu ou comme ici de multi-polygones.
>
Quand tu as des immeubles au milieu, c'est bien un multipolygone
Les exemples de Noémie sont bons.

> Pour ce qui est du routage, autant ça a un sens pour une place où le
> piéton peut passer n'importe où, autant pour le trottoir j'avoue ne pas
> voir d'intérêt (sauf pour les personnes chargées d'entretenir les voies) :
> la seule possibilité c'est de traverser "en dehors des clous", ça ne doit
> pas présenter d'intérêt notable et surtout un moteur peut le gérer avec un
> sidewalk=yes.
>
> Donc exit l'utilité pour le routage.
>
Qui a dit que le routage était pour les piétons ?
On ne trace pas le filaire des rivières pour les canoés.

> Pour le rendu, si c'est pour faire un rendu plus propre en 3D par exemple,
> pourquoi pas mais entrer simplement le fait qu'il y a un trottoir permet de
> bien représenter.
>
Non pas lorsque la surface change de largeur, avec des décrochés pour le
stationnement, etc...

> Mais dans tous les cas au pire je ferais des ways, pas des relations. Des
> relations ça n'a pas grand sens, ça complique. Tu peux très bien découper
> en bandes par rue (comme le trottoir est bitumé : par bandes et pas par
> multi-polygones !)
>
Là dessus c'est pertinent si la surface venait à changer (et ça nous
arrangerait par ailleurs, parce que les relations sont lourdes plus lourdes
que les surfaces).
Un changement de hauteur ou toute autre propriété permet de faire n surface
fermées contigües et se passer des relations

> De plus la cartographie c'est de la modélisation, pas de la représentation
> (à l'échelle 1:1 ? ;-)) exacte de la réalité.
>
Ça tombe bien, OSM n'est pas une base géographique :)

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

Re: [OSM-talk-fr] polygone pour représenter un trottoir

[François Lacombe]

Le lun. 29 avr. 2019 à 18:32, Antoine Riche via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Quand on "tourne au coin de la rue". Sur l'exemple
> https://www.openstreetmap.org/way/146662272 je ferais un way pour chacune
> des rues : Orderner, Jean Robert, Doudeauville, Francis Carco et
> Stephenson. Quant à décider si la jonction entre deux trottoirs est la
> bissectrice ou se prolonge le long de la rue "la plus importante", je pense
> qu'on peut laisser cela à la discrétion du mapper.
>

On ne droit pas parler de la même chose : un way pour chaque me fait plus
penser à du linéaire qu'à du surfacique.
Quand il n'y a pas de limite sur le terrain, certain vont couper au milieu,
d'autres sur les côtés, ca va être irrégulier.

> Sachant que sans le multipolygone, on doit repasser sur chaque contours de
> bâtiment, c'est plus redondant.
>
> Pas sûr de comprendre : dans les exemples donnés le inner définit le
> contour de l'ensemble des bâtiments du bloc. Il me semble y avoir le même
> niveau de redondance dans les deux façons de faire non ?
>
Non : dans le cas du surfacique, tu vas effectivement dessiner les
immeubles, d'une part et l'emprise du trottoir d'autre part. Les deux étant
adjacents, ils vont partager une limite commune tout le long de la rue.

> Le principe est de créer un graphe à partir de la surface, pour proposer
> un itinéraire réaliste (et la  distance correspond à cet itinéraire). Je ne
> maîtrise pas le sujet mais il existe des articles qui proposent des
> solutions :
>
>- https://www.tandfonline.com/doi/full/10.1080/10095020.2017.1399675
>-
>
> https://www.researchgate.net/publication/305272744_Integrating_Open_Spaces_into_OpenStreetMap_Routing_Graphs_for_Realistic_Crossing_Behaviour_in_Pedestrian_Navigation
>
> Cela nécessite de prendre en compte les obstacles se trouvant sur la
> surface pour les contourner ou les franchir.
>
D'accord, c'est ce qu'on ferait sur certains lacs en hydrographie là où le
réseau hydrologique n'est pas tracé.

Le lun. 29 avr. 2019 à 19:37, Jérôme Amagat  a
écrit :

> pourquoi pas un multipolygon, c'est plus proche de la réalité que de
> couper le trottoir pour en recommencer un juste après sans raison. c'est
> autour d'un patté de maison donc c'est pas si grand que çà.
>  par contre, vu que c'est un multipolygon, il y a plus de chance qu'il
> soit "cassé" par quelqu'un qui ne comprend pas comment çà marche.
>
Oui, comme tout il faut du contrôle là-dessus.

c'est peut être plus highway=pedestrian qu'il faut utiliser, mais comme
> j'ai toujours pas compris les différences et où l'on doit utiliser tous ces
> tags assez proche: highway=pedestrian, highway=footway, highway=path...
>
highway sur du surfacique me semble maladroit, jusque dans la sémantique

Je préfères cette représentation que d'utiliser le tag highway=pedestrian
> pour représenter ce que l'on appelle une place alors qu'il y a un parking
> au milieu voir une route...
>
+1

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

Re: [OSM-talk-fr] Les sous-stations ferroviaires (SNCF et les autres)

[François Lacombe]

Bonsoir Yves,

Le lun. 29 avr. 2019 à 11:28, Yves P.  a écrit :

> Bonjour,
>
> Sujet hyper spécialisé, qui peut intéresser une petite dizaine de
> contributeurs OSM dans le monde ? 
>

Si on regarde taginfo, 37k contributeurs sur la clé power. Tous ne sont pas
des spécialistes certes, mais c'est pas 10 non plus
https://taginfo.openstreetmap.org/keys/power

La même chose à quelques unités près pour railway
https://taginfo.openstreetmap.org/keys/railway


> En tant que contributeur lambda, comment savoir si un poste de
> transformation est équipé d’un convertisseur de fréquence ?
>
Bonne question, j'ai tenté de compléter le document avec des indications
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Traction_substations_extension#Comment_determiner_la_conversion_.3F


> Que peut-on éventuellement importer ?
>
En France, rien malheureusement, puisque la SNCF a adopté une licence non
compatible avec OdBL.
En revanche les tensions et fréquences sont normalement bien indiquées sur
le réseau français, donc en regardant les voies électrifiée aux abords des
sous-stations on peut s'y retrouver.
Les LGV sont toutes en 25kV AC 50Hz monophasé par exemple => Pas de
conversion dans ces sous-stations.


> Que peut-on observer sur place ? (J’ai photographié celle de Pannessières
>  sous toutes les
> coutures)
>
Les transformateurs sont généralement en intérieur, les redresseurs (si le
chemin de fer fonctionne en courant continu) sont souvent à l'intérieur
d'un bâtiment d'une taille assez importante.
Mais le but ici n'est pas de cartographier précisément chaque appareil mais
de qualifier le périmètre. Donc des informations sur les standards
électriques utilisés suffisent sans avoir besoin de voir ces appareils.

Le but est d'introduire une clé plus simple (sans namespace) avec des
> valeurs plus étoffées que yes/no pour indiquer si la sous-station produit
> du courant continu ou pas
>
> Pour le détail, acdc et acac ne sont pas très lisibles.
> Que pensez-vous de *ac/dc*, *ac/ac* ou *ac-dc*, *ac-ac* ?
>
Prenneur de vos avis, les valeurs sont proposées en l'état et peuvent
changer.
ac/dc est pas top, mais ce serait bon pour ac-dc ou ac_dc


> Pour info, il n’y a quasiment rien dans osm :
> https://taginfo.openstreetmap.org/search?q=ac-dc#values
>
> Et juste une simple interrogation : pourquoi ne pas indiquer la(les)
> fréquence(s) dans le cas d’une conversion ?
>
Parce que a fréquence est une propriété des appareils, pas des sites.
Reporter ces valeurs sur le site ne rend pas compte de subtilités des
systèmes installés à l'intérieur en plus d'introduire une redondance peu
utile.
Donc on défini des valeurs plus adaptées, et si on veut plus de détails on
ira chercher les appareils et leurs arrangements dans le site.

Il en est de même pour la tension ou le caractère monophasé/triphasé. Dire
qu'un poste électrique est triphasé n'a aucun sens, le dire pour un
transformateur oui.
Un peu comme dire qu'un parking est diesel parce que les voitures qui y
sont stationnées roulent au gasoil.


>
> Voilà, en espérant faire avancer le schmilblick.
>

Les commentaires sont utiles, merci

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

Re: [OSM-talk-fr] Les sous-stations ferroviaires

[François Lacombe]

Le lun. 29 avr. 2019 à 12:06,  a écrit :

> frequency:input=
>
> frequency:output=
>
> aurait l'avantage de la clarté (et de la facilitation pour la vérification
> du chaînage).
>
Le problème est que ce n'est pas toujours aussi clair sur la structure en
entrée/sortie.
Je ne serai pas étonné de trouver des sous-stations mixtes qui alimentent
en 25kV AC et en 1500V DC (ici ce serait donc conversion=acdc)

Il vaut mieux ne pas parler de fréquence (ou de tout autre propriété des
appareils) pour les sous-stations.

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

Re: [OSM-talk-fr] polygone pour représenter un trottoir

[François Lacombe]

Salut à tous

Noémie, je pense qu'il faut les deux, comme pour les rivières

Le linéaire servant à faire du routage, le surfacique à décrire ce que l'on
voit.
Et les deux sont utiles.

François

Le sam. 27 avr. 2019 à 14:03, djakk djakk  a écrit :

> Salut ! Moi je pense que tout est représentable sous forme de polygone,
> mais qu’on a pas forcément le temps du coup on simplifie en ligne voire en
> point. Reste le problème de la généralisation (la transformation du
> polygone en ligne) qui impose peut être de faire polygone + ligne.
>
> Julien « djakk »
>
>
> Le sam. 27 avr. 2019 à 13:39, Noémie Lehuby via Talk-fr <
> talk-fr@openstreetmap.org> a écrit :
>
>> Bonjour,
>>
>> que pensez-vous de cette modélisation des trottoirs, sous la forme de
>> multipolygones ?
>>
>> https://www.openstreetmap.org/relation/1979876
>> https://www.openstreetmap.org/relation/1979878
>>
>> Je comprends qu'il soit tentant de micro-cartographier les trottoirs
>> comme des polygones, mais je suis un peu sceptique.
>>
>> Le wiki est en tout cas formel, la représentation de ce type d'objet est
>> normalement uniquement sous forme de chemin :
>> https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dfootway
>>
>> --
>> nlehuby
>>
>>
>> ___
>> 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

[OSM-talk-fr] Les sous-stations ferroviaires (SNCF et les autres)

[François Lacombe]

Salut à tous,

Suite au vote mouvementé du mois dernier, je soumets une nouvelle
proposition, restreinte aux sous-stations ferroviaires chargées d'alimenter
les trains en énergie.
La proposition d'origine était beaucoup plus importante et cela l'a
sûrement desservi. Il faut donc découper et le 1er opus est ici.

Le document, pour l'instant en RFC avant le vote suivant les commentaires
reçus
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Traction_substations_extension

Le but est d'introduire une clé plus simple (sans namespace) avec des
valeurs plus étoffées que yes/no pour indiquer si la sous-station produit
du courant continu ou pas
C'est utile pour mettre en cohérence l'appareillage installé à l'intérieur
(et aussi confronter ça aux voies alimentées).

Le vote de cette nouvelle clé pourra déboucher sur un projet du mois afin
de nettoyer le tagging des sites français (environ 2500 pour SNCF Réseau +
tous les transport en commun électriques) et proposer un jeu de données
avec une meilleure licence que celle choisie par la SNCF (saluons l'effort
par ailleurs)

N'hésitez pas à donner votre avis

Bon weekend

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

[OSM-talk-fr] Proposition - Vote - Armement de supports aériens

[François Lacombe]

Salut à tous,

Le vote de la proposition de description des supports de lignes aériennes
s'ouvre aujourd'hui
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Lines_attachments

Derrière ce mot un peu barbare d'armement se cache le simple fait
d'attacher une ligne à un support, selon différentes techniques.
Le texte et les exemples sont normalement suffisamment explicites pour
comprendre ce dont il s'agit.

A noter que les nombreux commentaires reçus pendant 1 an d'écriture ont
permis d'aboutir à un résultat que je pense correct.

Pour voter, c'est sur la version anglaise comme d'habitude
https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_attachments

Merci par avance pour votre temps

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

Re: [OSM-talk-fr] Proposition - RFC - Armement des supports de lignes aériennes

[François Lacombe]

Le sam. 6 juil. 2019 à 21:34, Léo El Amri via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Ça me semble bon pour les cas autour de chez moi.
>
> Je me souviens cependant d'un poteau qui avait à la fois une jonction en
> T, un transformateur, et un interrupteur. J'ai du mal à voir comment le
> représenter avec un ensemble de tags power, line_attachment et type. Les
> attaches pour les cables sont ammarés au poteau, et ont donc un pont, et
> le transformateur est relié via ce pont. J'essaierai de me déplacer là
> bas pour le prendre en photo demain, mais il n'est accessible qu'à 30
> minutes à pied.
>

Merci Léo

Je pense que c'est un "simple" line_attachment=anchor, les bretelles
permettent justement aux deux lignes de s'ancrer sur le poteau.
On va en savoir plus si tu as une photo

Pour cette situation :
https://www.google.fr/maps/@46.0521127,6.1344669,3a,75y,354.55h,111.46t/data=!3m6!1e1!3m4!1sB6aFKQ4UPGtKs9k6GeARiA!2e0!7i13312!8i6656
On peut ajouter simplement line_attachment=anchor
Ou bien, pour bien signifier qu'il y a deux niveaux d'armement du poteau :
line_attachement=(anchor)|(anchor)

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

[OSM-talk-fr] Attribut ref sur les ronds point : la question de Montpellier

[François Lacombe]

Bonsoir

Je vous relaye cette interrogation, postée à bon escient sur le wiki, par
la métropole de Montpellier
https://wiki.openstreetmap.org/wiki/FR_talk:Tag:junction%3Droundabout

A mon sens les ref devraient aller sur des relations, mais bon, on va pas
ressortir cette vieille discussion haha :)

Bonne soirée

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

Re: [OSM-talk-fr] building=amenity

[François Lacombe]

+1 building renseigne même le contenant, alors qu'amenity désigne un
service rendu.

Une "amenity" peut aller dans un street cabinet, sur un poteau, contre un
mur...
Mélanger les deux n'est pas une bonne idée.

Un peu comme si dans le cas waterway=canal + tunnel=flooded on disait
tunnel=waterway + waterway=canal
(oui j'ai des exemples partisans)

François

Le mar. 2 juil. 2019 à 21:39, marc marc  a
écrit :

> Le 02.07.19 à 21:31, osm.sanspourr...@spamgourmet.com a écrit :
> > Une objection à repasser à building=train_station ?
>
> Building renseigne l'apparence.
> je ne connais pas la gare de Rennes mais si le bâtiment
> à l’apparence d'une gare, building=train_station est adapté.
> Je ne vois pas ce que "apparence d'un amenity" voudrait dire.
> il y en a plusieurs sur Rennes dont par exemple un immeuble à
> appartement https://www.openstreetmap.org/way/80741999/history
> ___
> 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] Démontage partiel ligne haute tension

[François Lacombe]

Bonsoir à tous

Le consensus suivant semble s'établir pour les cas suivants :
* Ligne électrique hors tension et toujours présente : disused:power=line
* Ligne électrique visible sur les vues aériennes, mais supprimée du
terrain : removed:power=line

TOUTEFOIS :
Avec le mécanisme (complexe) des circuits sous forme de relation, nous
devrions laisser power=line et supprimer la relation représentant le
passage du courant à l'intérieur de la ligne
Un peu comme si une route n'était plus empruntée par les lignes de
transport en commun. La route est toujours présente, mais les bus n'y
passent plus.
Vu que cela concerne encore un nombre restreint de lignes, et les plus
grosses, nous ne pouvons pas nous baser là-dessus pour l'instant.
Explications :
https://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/France#Circuits_et_routage_sur_le_r.C3.A9seau

Au titre du principe de vérifiabilité, si l'ouvrage a disparu du terrain
(ce qui ne semble pas correspondre au cas de départ de la discussion), il
faudrait le supprimer (removed:power=line est un non sens au regard de ce
principe)
Je suis pour conserver une part d'historique, mais là ça va être difficile
à justifier.

A+

François

Le mer. 17 avr. 2019 à 21:23, Yves Pratter via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> *removed:power=line* est bien aussi (cf.
> https://wiki.openstreetmap.org/wiki/Lifecycle_prefix)
>
> _
> Yves
>
> D'après TagInfo :
> 1 540
>
>- removed*:power*
>
>
>
>
>
>1. 1 124
>
>
>- disused*:power*
>
>
> 924
>
>- demolished*:power*
>
>
> 620
>
>- was*:power* 
>
> 209
>
>- dismantled*:power*
>
>
>
>
> 201
>
>- razed*:power* 
>
>
>
> Le mer. 17 avr. 2019 à 21:00, marc marc  a
> écrit :
>
>> Le 17.04.19 à 20:43, Laurent Combe a écrit :
>> > Bonjour dans mon secteur j'ai une ligne 63000 V dont les cables
>> > viennent d'être déposés
>> >
>> > si j'enleve le cable j'ai peur qu'ils reviennent suite à une
>> > contribution malheureuse
>> > quel tag mettre dans cette situation ?
>>
>> was:power=line ou n'importe quel cycle de vie du genre removed:
>> + end_date si tu le souhaites (éventuellement limité au mois
>> ou à l'année si tu sais pas précisément quand)
>> https://wiki.openstreetmap.org/wiki/Lifecycle_prefix
>> idem sur les poteaux le jour où ils sont démonté
>> ___
>> 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

[OSM-talk-fr] Proposition - Approuvée - Armement de supports aériens

[François Lacombe]

Salut à tous,

Je n'avais pas pris le temps de le faire ici, voici donc le bilan du vote
de la proposition concernant les armements de supports aériens.
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Lines_attachments

23 (24 maintenant) votes exprimés en sa faveur ont permis son adoption.
Merci à tous ceux qui se sont investi pour faire leurs commentaires et
voter le moment venu.

Évidemment c'est comme à mon habitude très technique et non moins un sujet
qui démontre la force d'OSM.
Les poteaux électriques comme télécom sont actuellement essentiels à
l'installation de la fibre optique en rural comme en urbain parfois.
Leur recensement ainsi que certaines caractéristiques comme celle-ci
intéresse les acteurs de ce déploiement (qu'ils ne manqueront pas
d'utiliser en respectant la licence et la communauté), j'en ai parlé au
sotm cette année.

N'hésitez donc pas à faire un petit tour autour de chez vous et apporter
votre pierre à l'édifice si vous en avez l'occasion
Les poteaux en question sont visibles sur le rendu standard et sur
OpenInfraMap. Ce dernier pourra certainement rendre la clé line_attachment
dans les prochaines semaines.

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

Re: [OSM-talk-fr] [TELECOM] NRA que je ne sais pas renseigner.

[François Lacombe]

Bonsoir

Le NRA en question a été trouvé depuis, bonne intégration avec un
street_cabinet (il faut préférer les majuscules dans ref:FR:PTT et il est
possible de mettre ref=NRA/YCP)
Ces NRA (les ZO, MeD...) sont financés par les collectivités,
l'exploitation de la partie cuivre est une prestation assurée par Orange.
Il est possible d'ajouter un owner=* correspondant à la collectivité qui
l'a financé (il y a souvent une pancarte qui donne le nom dessus). Le reste
des NRA est bien en propriété Orange.

L'un des arguments pour leur implantation alors que la fibre arrive est que
les infrastructures pourraient être réutilisées.
C'est à mon avis ce que peuvent signifier les inscription relatives au FTTH.
Voir ceci par exemple :
https://twitter.com/pindrow/status/1161175736159547393

Après un petit passage de 1000km dans les pyrénéens ce weekend, je vais
aussi en ajouter pas mal

A bientôt

François

Le dim. 11 août 2019 à 17:22, Jacques Lavignotte  a
écrit :

>
>
> Le 11/08/2019 à 16:26, deuzeffe a écrit :
> > YCP86 ? cf
> https://www.ariase.com/couverture/vienne-86/nra/ycp86-86076ycp
>
> Pile-poil ! C'est lui.
>
> Merci FF !
>
> Accessoirement :
> Une des portes du NRA porte (!) une étiquette qui parle de « Bientôt
> fibre/Région/Gnagna » Un NRA peut donc recevoir des équipements optiques ?
>
> J.
> --
> GnuPg : C8F5B1E3 Because privacy matters.
>
>
> ___
> 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] OpenInfraMap - suggestion

[François Lacombe]

Bonsoir,

Très bonne idée que ces messages, merci pour vos retours.
Effectivement, Russ est le seul à maintenir le code du style comme de
l'import des données OSM.
Un (gros) rechargement est nécessaire pour prendre en compte de nouvelles
clés, j'espère qu'il y parviendra prochainement.

J'ai créé une issue sur le githib pour les mauvais liens, je pensais que le
problème était déjà connu
https://github.com/openinframap/styles/issues/55

Il ne faut pas hésiter à en créer d'autres au besoin

François

Le mar. 13 août 2019 à 16:59, Francois Gouget  a écrit :

> On Mon, 12 Aug 2019, David Crochet wrote:
>
> > Bonjour
> >
> > Je ne sais pas si les contributeur a OpenInfraMap sont également sur
> > cette liste, mais Il serait intéressant de modulé l'opacité des données,
> > car les données "Oil & Gaz" étant d'une couleur très clair, il est pas
> > facile de les visualiser.
>
> Si je peux aussi me permettre une suggestion, ce serait vraiment
> pratique pour s'y retrouver d'avoir le nom de 3 où 4 villes dans le fond
> de carte à chaque niveau de zoom.
>
> Par exemple à l'heure actuelle typiquement les seuls éléments qui ont un
> nom sont les postes électriques comme ceux de Asnière-sur-Nouère et
> Fléac. Mais ce n'est pas très parlant (à part peut-être pour les gens du
> coin) et avoir un label "Angoulème" là où se trouve la grande ville
> proche permettrait tout de suite de savoir qu'il s'agit de sa banlieue.
>
>
> Il y a aussi un problème avec les liens vers les noeuds OpenStreetMap
> (mais je suppose qu'il s'agit d'un problème déjà connu).
> Par exemple :
> https://www.openstreetmap.org/way/1399460508
> vs. https://openstreetmap.org/node/1399460508
>
> --
> Francois Gouget   http://fgouget.free.fr/
> 1 + e ^ ( i * pi ) =
> 0___
> 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] Proposition - RFC - Bornages des réseaux souterrains

[François Lacombe]

Salut à tous,

Une proposition dont la discussion a commencé avant l'été dans sa version
anglaise est désormais disponible en français sur le wiki
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Utility_markers_proposal#Pipelines

Elle concerne la description des bornes visibles sur le terrain. On
décrivait déjà les bornes pour les gazoducs et pipelines, mais elles
peuvent concerner d'autres domaines (électricité, télécoms...)
C'est pourquoi il est proposé une nouvelle clé qui permettra de toutes les
décrire sans avoir à le faire dans chaque domaine.

C'est comme les Pokémon, il faut se promener dans les hautes herbes pour en
trouver.

Les quelques remarques reçues jusque là ont été prises en compte, le vote
va pouvoir débuter prochainement.

Bon weekend

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

Re: [OSM-talk-fr] Traductions de page wiki OSM en français

[François Lacombe]

Le jeu. 29 août 2019 à 10:52, marc marc  a
écrit :

> si tu modifies le dataitem, rien ne met à jour la page wiki et les
> outils ont donc des informations différentes. pire même la page
> wiki peux afficher une info différente du dataitem.
>

Bonjour Marc,

Effectivement, lorsqu'un dataitem est mis à jour à la main, il faudrait
supprimer purement et simplement le champ correspondant de la page wiki
La template va normalement chercher automatiquement le contenu dans le
dataitem de sorte à ne pas avoir d'informations discordantes

Il reste que cette pratique risque de poser problème pour l'instant aux
outils qui ne vont chercher que dans les pages wiki et pas dans les
dataitems

Dès que ce changement sera fait, on pourra commencer à vider les pages wiki
de ce contenu redondant.

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

[OSM-talk-fr] Cartographie nationale du transport de gaz

[François Lacombe]

Salut à tous,

J'ai trouvé le fichier suivant sur data.gouv (ok, pas par hasard)
https://www.data.gouv.fr/fr/datasets/carte-du-reseau-de-transport-de-gaz-sur-la-france-metropolitaine/

Les données semblent provenir d'ici :
http://cartelie.application.developpement-durable.gouv.fr/cartelie/voir.do?carte=CanalisationsTMD=CEREMA

Vu les nombreux échanges sur le sujet que j'ai eu avec certains, et le
linéaire déjà conséquent de réseau présent sur OSM (12 500km environ sur 27
000), je ne pense pas qu'importer en direct soit pertinent.
En revanche cela peut dépanner pour lever des imprécisions, ou trouver des
bornes, nous aider sur le terrain.
Il y a également la cartographie depuis les vues aériennes des périmètres
des stations, etc...

Si jamais vous vous promenez à la campagne, repérer les bornes jaunes est
un sujet d'intérêt pour OSM, pensez-y.

La diffusion de ces informations sous le régime de l'article L312-1-1 du
CRPA est toujours questionné par une circulaire (BSEI 2009-218).
En repérant les bornes sur le terrain et en traçant tout ou partie des
canalisations par ce biais, OSM neutralise le sujet.

Bonne après-midi

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

[OSM-talk-fr] Cartographie du réseau ferré avec Graou

[François Lacombe]

Un sujet ferroviaire cette fois
Pour ceux qui suivent les progrès fait par le projet Graou, vous avez
surement vu passé cette nouvelle :
https://twitter.com/NicolasW_GRAOU/status/1164555227149852674?s=20

Graou c'est la Gestion des Roulement Assistée par Ordinateur de la SNCF, en
gros l'application interne qui permet aux cheminots de connaître leur
matériel, les horaires des trains, et plein d'autres choses, développée par
et pour les gens du métier.
Elle va être complétée avec une couche cartographie, que le développeur
nous fait le plaisir d'ouvrir en public.
https://map-beta.graou.info/#7/48.6/3

Elle affiche un fond de plan vectoriel d'OpenMapTile (pas des plus à jour,
si certains ici sont intéressés pour appuyer la SNCF dans ce sens avec un
fond de carte plus à jour), des données en opendata (filaire des voies,
gares, sous-stations) mais des infos moins ouvertes comme le cantonnement
(je ne crois pas l'avoir vu sur le site).
Bref, une très belle démonstration en plus de la réutilisation dans un
projet aussi industriel des composants de notre écosystème.

Bonne découverte

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

Re: [OSM-talk-fr] Traductions de page wiki OSM en français

[François Lacombe]

Salut à tous,

J'ai apporté ma pierre à l'édifice de la traduction avec les pages
suivantes :
https://wiki.openstreetmap.org/wiki/FR:Tag:pipeline%3Dvalve
https://wiki.openstreetmap.org/wiki/FR:Key:valve
https://wiki.openstreetmap.org/wiki/FR:Key:handle
https://wiki.openstreetmap.org/wiki/FR:Key:actuator
https://wiki.openstreetmap.org/wiki/FR:Key:turn_to_close
https://wiki.openstreetmap.org/wiki/FR:Key:line_attachment
https://wiki.openstreetmap.org/wiki/FR:Tag:line_attachment%3Dsuspension
https://wiki.openstreetmap.org/wiki/FR:Tag:line_attachment%3Danchor
https://wiki.openstreetmap.org/wiki/FR:Tag%3Aline_attachment%3Dpin
https://wiki.openstreetmap.org/wiki/FR:Tag%3Aline_attachment%3Dpulley
https://wiki.openstreetmap.org/wiki/FR:Key:telecom

A noter que désormais, pour les pages existant depuis un certain temps, les
traductions des infosbox en tête de page peuvent être directement faites
dans les DataItems correspondants
Pour cela, dans l'infobox, cliquez sur le petit crayon gris à côté de la
description. Un nouveau monde va s'ouvrir à vous.
Il suffit normalement de supprimer le champ dans le wikicode de l'infobox
pour qu'il aille automatiquement chercher ce qui est disponible dans le
dataitem (photos, primitives autorisées, statut, combinaisons...)
Les pages seront plus facilement tenues en cohérence entre les différentes
langues.
Plus d'informations : https://wiki.openstreetmap.org/wiki/Data_items
(Désolé pas encore disponible en français)

Bonne soirée

François


Le mar. 27 août 2019 à 19:34,  a écrit :

> J'ai un soucis avec https://wiki.openstreetmap.org/wiki/FR:Key:abandoned:
>
> J'ai l'impression d'avoir fait planter le serveur (j'ai juste demander à
> éditer un wiki code, donc c'est sans doute un hasard).
>
> --
>
> [39d923ab34c0d9133165ff3b] 2019-08-27 17:33:07: Erreur fatale de type «
> Wikimedia\Rdbms\DBQueryError »
>
> --
>
> MediaWiki internal error.
>
> Original exception: [c100f4745417949dd22aaf0c] 2019-08-27 17:30:56: Fatal
> exception of type "Wikimedia\Rdbms\DBQueryError"
>
> Exception caught inside exception handler.
>
> Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to
> show detailed debugging information.
>
>
> Le 25/08/2019 à 13:57, gnrc69 via Talk-fr - talk-fr@openstreetmap.org a
> écrit :
>
> Hello tout le monde,
>
> Les pages suivantes sont aussi traduites en FR :
> https://wiki.openstreetmap.org/wiki/FR:Key:abandoned:
> https://wiki.openstreetmap.org/wiki/FR:Séparateur_de_valeur_point-virgule
>
> Merci aux relecteurs potentiels
>
> gnrc69 - OSM Lyon
>
> --
> *De: *g...@laposte.net
> *À: *"severin.menard" 
> , "Discussions sur OSM en français"
>  
> *Cc: *hot-francoph...@openstreetmap.org
> *Envoyé: *Vendredi 9 Août 2019 15:24:17
> *Objet: *Re:  [OSM-talk-fr] Traductions de page wiki OSM en français
>
> Hello tous,
>
> Je viens de terminer la traduction en FR des pages :
>
> https://wiki.openstreetmap.org/wiki/Key:drinking_water
> https://wiki.openstreetmap.org/wiki/FR:Espaces_de_noms
>
> Si certains veulent faire une relecture, car mon prof de langue a encore
> beaucoup à apprendre, il s'appelle G...gle !
>
> PS: ATTENTION pour "abandoned", il existe une page EN et partiellement FR
> https://wiki.openstreetmap.org/wiki/Key:abandoned: dont la traduction est
> à terminer ;
> mais aussi une page EN non traduite en FR
> https://wiki.openstreetmap.org/wiki/Key:abandoned qui devrait se limiter
> aux recommandations de non-utilisation de abandoned=*
> Il pourrait aussi être judicieux de fusionner les deux pages.
>
> Amicalement
> gnrc69 OSM Lyon
>
> --
> *De: *"severin.menard via Talk-fr" 
> 
> *À: *talk-fr@openstreetmap.org, hot-francoph...@openstreetmap.org
> *Cc: *"severin.menard" 
> 
> *Envoyé: *Jeudi 11 Juillet 2019 22:03:58
> *Objet: * [OSM-talk-fr] Traductions de page wiki OSM en français
>
> Bonsoir à tous,
>
> J'ai traduit en français la semaine dernière la page wiki intitulée *Any
> tag you like* qui explique les fondamentaux de la création d'attributs
> dans OSM :
>
> https://wiki.openstreetmap.org/wiki/FR:Cr%C3%A9er_un_attribut_qui_manque
>
> J'ai remarqué que pas mal de pages wiki en lien dans cette page restaient
> en mal de traduction en français, si certains sont motivés :
>
> https://wiki.openstreetmap.org/wiki/Names#Localization
> https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator
> https://wiki.openstreetmap.org/wiki/FR:Espaces_de_noms
>
> Même chose pour certaines clés, par exemple :
>
> https://wiki.openstreetmap.org/wiki/Key:drinking_water
> https://wiki.openstreetmap.org/wiki/FR:Key:abandoned:
>
> Séverin
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> 

Re: [OSM-talk-fr] Removed "WikiProject" prefix

[François Lacombe]

Bonsoir / Hi

Le mer. 4 sept. 2019 à 11:55, dcapillae  a écrit :

>
> WikiProject Power networks/France
>

Pour celui-ci, je m'en charge.
Préalablement, j'ai proposé une séparation de ce projet en deux : l'un pour
la production d'électricité, l'autre pour les réseaux la transportant.
D'ici une dizaine de jours, si il n'y a pas d'objection explicite,
j'opérerai la séparation pour toutes les langues, en ne reportant pas le
WikiProject.

--
This one is my business
Before any removal of WikiProject, I prefered propose a split between two
topics : power generation and power transmission.
If there is no objection until 10 days, I'll do that split without using
Wikiproject prefix in new pages names.

Bonne soirée

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

Re: [OSM-talk-fr] Removed "WikiProject" prefix

[François Lacombe]

Bonsoir / Hi

La page Télécoms vient d'être renommée, ainsi que le sous-projet français
https://wiki.openstreetmap.org/wiki/Telecoms
https://wiki.openstreetmap.org/wiki/Telecoms/France

--
i've just moved Telecoms project
https://wiki.openstreetmap.org/wiki/Telecoms

French subpage also
https://wiki.openstreetmap.org/wiki/Telecoms/France


All the best

François

Le ven. 6 sept. 2019 à 00:08, François Lacombe 
a écrit :

> Bonsoir / Hi
>
> Le mer. 4 sept. 2019 à 11:55, dcapillae  a écrit :
>
>>
>> WikiProject Power networks/France
>>
>
> Pour celui-ci, je m'en charge.
> Préalablement, j'ai proposé une séparation de ce projet en deux : l'un
> pour la production d'électricité, l'autre pour les réseaux la transportant.
> D'ici une dizaine de jours, si il n'y a pas d'objection explicite,
> j'opérerai la séparation pour toutes les langues, en ne reportant pas le
> WikiProject.
>
> --
> This one is my business
> Before any removal of WikiProject, I prefered propose a split between two
> topics : power generation and power transmission.
> If there is no objection until 10 days, I'll do that split without using
> Wikiproject prefix in new pages names.
>
> Bonne soirée
>
> François
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Manque d'attribution : je suis estomaquée

[François Lacombe]

Merci Christian, en effet on sors la mitraillette à rappels à l'ordre en ce
moment.
J'avais déjà vu ce cas des tuiles OSM utilisées dans l'API Google, qui
évidemment pose son logo par dessus

Avec Donat on a ce cas également avec EDF
https://twitter.com/drobaux/status/1156104641056108546

Aucune réaction, je veux bien qu'on soit en août, mais ce n'est pas la 1ere
fois.
Je leur avait déjà fait remarquer des impressions d'OSM (rendu France) sur
des panneaux sur site qui ne disposaient pas d'attribution.
Tout va bien au pays du sans-gêne.

Il y a également eu le cas de l'ASN
https://twitter.com/InfosReseaux/status/1147196234500902913

Et du Cerema
https://twitter.com/InfosReseaux/status/1148863374689808389

Bon lundi

François

Le lun. 5 août 2019 à 10:10, Christian Quest  a
écrit :

> Et voilà... https://twitter.com/cq94/status/1158287747381170176
>
> C'est souvent le plus efficace ;)
>
> Le lun. 5 août 2019 à 09:04, deuzeffe  a écrit :
>
>> On 05/08/2019 08:24, Cyrille37 OSM wrote:
>>
>> Bonjour,
>>
>> >>> Si quelqu'un de plus aguerri que moi pense qu'il y a un détournement
>> >>> manifeste, le gars peut être interpellé sur son twitter :
>> >>> https://twitter.com/TOURISMEMARSEIL
>> >> La carte ressemble effectivement beaucoup à OSM. Leur site, va taper à
>> >> la fois sur maps.google.com mais aussi sur tile.openstreetmap.org
>> >
>> >
>> > Ils utilisent le javascript de Google maps et les tuiles
>> > d'openstreetmap.org.
>>
>> Merci à vous deux pour les explications. Et donc, il y a qq chose à
>> faire/lui dire pour lui faire respecter la licence d’utilisation d'osm ?
>>
>> --
>> deuzeffe, toujours pas revenue du procédé.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Christian Quest - OpenStreetMap France
> ___
> 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] Proposition - Approuvée - Armement de supports aériens

[François Lacombe]

Merci pour les retours :)

Le mar. 6 août 2019 à 21:42, Christian Quest  a
écrit :

>
> line_attachment=wtf ?
>

Celle là je n'y avais pas pensé, mais on va la garder, ne serait-ce que
pour documenter les nombreuses variations françaises par endroits !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Manque d'attribution : je suis estomaquée

[François Lacombe]

Bonsoir Marc,

Le mar. 6 août 2019 à 20:42, marc marc  a écrit :

> je vous trouve très dur, inutilement dur... sortez de votre bulle !
>

Dans la forme pour ce coup, certainement.
Quoi que je n'en ai pas rajouté vu que beaucoup de contacts sont partis
pour ce cas-ci.

Sur le fond en revanche, je pense que nos signalements pressants sont
légitimes.
Cela fait des années que je passe beaucoup de temps à vérifier
l'utilisation du contenu que je publie en CC (pas pour osm donc).
Effectivement peu de monde ne respecte.
J'ai du envoyer des centaines de mails, à des acteurs publics comme privés
qui réutilisent des photos sans respecter les conditions (certains n'ont
jamais donné suite ni pris de mesures, tout va bien)

Avoir des acteurs qui ont encore cette approche binaire gratuit/payant
après tout le remue-ménage autour des directives copyright en tout genre,
du domaine publique et autre, c'est un peu gros (ou alors c'est qu'on en a
pas assez parlé).
C'est un autre sujet, mais je pense que ce serait aussi à eux de sortir de
leur bulle pour que tout le monde se rencontre.
Les efforts ne peuvent pas toujours venir de ceux qui font, devant en plus
être indulgent avec ceux qui profitent.

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

Re: [OSM-talk-fr] Faites s'il vous plaît suivre au gestionnaire du site : https://festival-avignon.com/fr/acces-au-festival

[François Lacombe]

Bonsoir,

C'est ajouté, en incluant les actions de Philippe L
https://twitter.com/__phiphou__/status/1158424031227469824

François

Le mer. 7 août 2019 à 10:09, Jacques Lavignotte  a
écrit :

> Bookmarqué.
>
> Merci. J.
>
> Le 07/08/2019 à 08:26, deuzeffe a écrit :
> > Une màj de
> > https://wiki.openstreetmap.org/wiki/FR:Lacking_proper_attribution
> > peut-être ?
> >
> > On 06/08/2019 20:53, Jacques Lavignotte wrote:
> >> Bonjour,
> >>
> >>
> >> https://festival-avignon.com/fr/acces-au-festival
> >>
> >>   utilise un fond de carte @OSM_FR mais sans l'indiquer nulle part :(
> >>
> >> Pourtant l'attribution n'est pas une option et c'est bien expliqué sur
> >> https://www.openstreetmap.org/copyright
> >>
> >> Merci d'avance de faire le nécessaire.
> >>
> >> Jacques Lavignotte, contributeur OSM.
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
>
> --
> GnuPg : C8F5B1E3 Because privacy matters.
>
>
> ___
> 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] Sotm Heidelberg : on y va ensemble ?

[François Lacombe]

Salut à tous,

Ca ne sera pas encore pour cette année me concernant.
D'autres contraintes me retiennent à Paris ce weekend là.
Je nettoie le framacalc des infos que j'avais pu y mettre.

Par contre je serai bien présent au Hackweekend d'Octobre, tel qu'abordé au
SOTM-Fr.

Bon weekend !
François

Le ven. 19 juil. 2019 à 11:23, Christine Karch  a
écrit :

> Bonjour,
>
> le moment il y a "Early Bird" chez SotM. Vous pouvez acheter les tickets
> pour la communauté à EUR 75. Le prix régulier pour la communauté est EUR
> 120. Early Bird va se terminer le 21 juillet.
>
> Christine
>
> ___
> 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] filaire rivières

[François Lacombe]

Bonjour Jean-Yvon,

Si le politique a effectivement fait modifié les bases descriptives pour
masquer d'autres problèmes c'est déplorable.
On lit beaucoup de choses à ce sujet, comme d'habitude cela prend du temps
de démêler le vrai du faux.

En ce qui me concerne sur OSM, je déclare tous les cours d'eau, c'est plus
simple :)

Bon weekend

François

Le sam. 20 juil. 2019 à 11:17,  a écrit :

> Certains ont des méthodes peu orthodoxes pour améliorer le taux de
> couverture d'OpenStreetMap :
>
> // cyber action N° 1130: Indre-et-Loire : 3 000 km de ruisseaux rayés de
> la carte par la préfecture
> Près de 43% des cours d'eau ont disparu des cartes dressées par la
> préfecture d'Indre-et-Loire.
> https://is.gd/cVu5aa
>
> Si je le dis sur un ton humoristique, le problème est réel : quelle est la
> pertinence de Sandre si le politique s'en mêle ? N. B. : dans certaines
> régions, les associations environnementales ont été vigilantes et le
> filaire est resté à peu près stable.
> Mais si elles sont plus vigilantes c'est aussi que la qualité de l'eau y
> pose plus de problèmes...
>
> 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

[OSM-talk-fr] Les actionneurs (portes automatiques, barrières, plots routiers, vannes)

[François Lacombe]

Salut à tous,

J'ai récemment un peu avancé dans la traduction de la doc de la clé
actuator=*, permettant d'indiquer la nature de l'actionneur mécanique
mettant différents systèmes en mouvement.
https://wiki.openstreetmap.org/wiki/FR:Key:actuator

Cela va de la porte automatique, aux plots routiers amovibles en passant
par les vannes (but initial de cet clé).
La liste des valeurs possibles initiale est disponible sur la proposition
votée en début d'année
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Pipeline_valves_proposal#Actionneurs

Ce serait pas mal d'initier l'usage de la clé sur les dispositifs routiers
de régulation de la circulation (barrières, plots, portails) et sur les
portes automatiques, cela peut servir pour l'accessibilité.
Seules les valeurs electric_motor, pneumatic_cylinder et hydraulic_cylinder
devraient être utiles pour cela (on va laisser solenoid et thermostatic
pour plus tard).
https://wiki.openstreetmap.org/wiki/FR:Tag:actuator%3Delectric_motor
https://wiki.openstreetmap.org/wiki/FR:Tag:actuator%3Dhydraulic_cylinder
https://wiki.openstreetmap.org/wiki/FR:Tag:actuator%3Dpneumatic_cylinder

Dans le cas de dispositifs manuels, la clé handle pourrait également servir
https://wiki.openstreetmap.org/wiki/FR:Key:handle

La liste des valeurs est aussi disponible sur la proposition (les valeurs
n'étant pas toutes utilisées vu de taginfo, la liste ne les donne pas
toutes)
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Pipeline_valves_proposal#Commande_manuelle

Preneur de vos remarques pour ces cas d'usages, y compris indiquant des
clés existantes plus particulières ou des cas non documentés.

Bonne soirée

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

Re: [OSM-talk-fr] Station d'épuration

[François Lacombe]

Bonsoir Jérôme,

Ce serait une bonne idée de décrire ces installations
Il manque néanmoins quelques tags pour cela, à commencer par la clé
concentrant toutes les activités humaines du petit cycle de l'eau (du
captage à la restitution des eaux usées).
waterway=* ne convient pas
man_made=* est trop générique (man_made=waterworks doit être redéfini)
pipeline=* est quant à lui trop particulier

L'idée est de regrouper les stations d'épuration (UDEP/STEP), les stations
de potabilisation, désalinisation (qui ne produisent pas nécessairement de
l'eau potable), les stations de pompage.
Ce serait des sites et il faudrait ensuite avoir des clés pour les nombreux
appareils qu'on y trouve : cuves, pompes, plomberie... Il y a déjà les
vannes de décrites avec pipeline=valve.

Si il y a des intéressés pour faire progresser ce point, il y a encore pas
mal de propositions à écrire sur le sujet.

Bonne soirée

François

Le jeu. 12 sept. 2019 à 19:12, Jérôme Amagat  a
écrit :

> Bonjour,
> On trouve ici :
> http://www.sandre.eaufrance.fr/atlas/srv/fre/catalog.search#/metadata/ebef2115-bee5-40bb-b5cc-4593d82ba334
> les stations de traitement des eaux usées de France. ça semble pas mal
> géocodé.
> Je penses que l'on pourrai les intégrer grâce à osmose.
>
> Mais avant ça, je voulais demander ce que vous pensez de la référence :
> Dans la base de donnée on a un "CdOuvrageDepollution", est ce qu'on
> l'ajoute à osm dans un ref? si oui, quel ref? il y a déjà ref:sandre=* (
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:sandre) qui existe mais
> que l'on trouve que sur des cours d'eau. Ici se serait sur des
> man_made=wastewater_plant.
>
> A partir de cette référence on peut avoir des info sur le site
> sandre.eaufrance.fr et assainissement.developpement-durable.gouv.fr
> Par exemple avec le code 060901365002 on a :
>
> http://assainissement.developpement-durable.gouv.fr/fiche.php?code=060901365002
> http://www.sandre.eaufrance.fr/geo/SysTraitementEauxUsees/060901365002
> Donc possibilité d'ajout à tag2link (différent des ref:sandre déjà
> existant sur les rivières)
>
> ___
> 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] Gestion des documentation d'attributs

[François Lacombe]

Bonsoir Roland,

Merci pour l'effort d'avoir rédigé cela en français.
Je n'ai pas pu suivre toute la discussion sur la liste internationale.

Simplement, as-tu bien pris en compte cette évolution sur le wiki ?
https://wiki.openstreetmap.org/wiki/Data_items

Sans trop changer notre manière de faire, les Data Items apportent la
structuration nécessaire pour éviter les différences trop importantes de
traduction.
D'autres proposaient Git, mais je ne pense pas que ce soit nécessaire.

Bon SotM à toi

François

Le mar. 10 sept. 2019 à 06:40, Roland Olbricht  a
écrit :

> Bonjour,
>
> J'ai le devoir de parler de la gestion des règles des attributs sur la
> SotM et j'aimerais développer cette opportunité vers quelque truc
> d'utile à long terme. Pour m'assurer que je suis sur la bonne voie et
> non pas involontairement après un programme personnel, j'aimerais vous
> demander de commenter les résultats énumérés ci-dessous.
>
>
> Insuffisant flux d'information
>
> Bien que de nombreuses parties du projet OpenStreetMap soient bien
> traduites, les documentation des attributs comportent des lacunes
> importantes. Sur un échantillon aléatoire de 10 balises, le nombre de
> langues déclarées varie entre 2 et 18, mais peu sont complètes et à jour
> (échantillon : 2 sur 10 pour l'allemand, 3 sur 10 pour le français).
>
> Un autre type de flux d'informations imparfait est que les définitions
> des attributs peuvent être modifiées sur la page wiki longtemps après
> que l'attribut soit largement utilisé.
>
> Le cas inverse d'un attribut introduit sans aucune documentation se
> produit également. Bien que cela se produise habituellement assez
> lentement pour donner un sens aux données ajoutées par les utilisateurs
> personels, une importation ou une édition organisée pourrait être en
> mesure de décaler considérablement le sens de facto d'un attribut,
> n'importe qu'elle soit largement utilisée, documentée, les deux, ou aucune.
>
>
> Plus des structures requirés
>
> Les problèmes de traduction ont été confondus avec un autre problème:
> Différentes caractéristiques peuvent sembler très différentes d'une
> région à l'autre. Par exemple, highway=primary et highway=unclassfied
> par rapport à highway=track ont besoin d'examples différents en
> Allemagne et dans les métropoles américaines, d'une part, et en Islande
> ou en Afrique rurale, d'autre part. Il est facile de mélanger cela avec
> la traduction dans la langue prédominante de la région, mais les défis
> du attribution en Belgique, au Canada et au Niger sont sensiblement
> différents, bien que les trois pays aient le français comme langue
> officielle. Inversement, il n'y a aucune raison valable de modifier les
> règles d'attribution dans chaque bloc de maisons à Bruxelles.
>
> De plus, les gens ont souvent des termes de recherche différents des
> noms d'attributs anglais britanniques ou de leurs traductions, et le
> moteur de recherche wiki est tristement célèbre pour ses mauvaises
> performances. Avoir des mots-clés explicites pour attirer l'attention
> d'un mappeur sur la liste des balises éventuellement appropriées peut
> aider.
>
> L'un des principaux problèmes à l'origine du concept de Proposal est le
> suivant qu'il interagit avec de nombreux attributs de manière non
> triviale et qu'il n'est pratiquement jamais correctement appliqué à
> toutes les définitions d'attributs affectées. Une Proposal est au moment
> une page supplémentaire bien qu'elle devrait avoir beaucoup plus
> d'impact qu'un commit Git, en regroupant les modifications sur plusieurs
> pages de définition d'attributs dans un seul groupe de modifications.
>
>
> Règles et leur légitmation
>
> Quelle légitimation a un processus si seulement une poignée de personnes
> ont le temps d'écrire des mails sur une liste de diffusion et d'écrire
> des pages wiki sont impliquées ? En particulier, si les propositions
> finissent par être pleines de contradictions ou de termes vagues et
> laissent les réponses nécessaires indéfinies. Pourtant, ce sont toujours
> ces personnes qui ont fait preuve de l'endurance à long terme nécessaire
> pour assurer l'entretien et qui font le travail. Par conséquent, tout
> changement visant à remplacer les processus par de meilleurs processus
> doit viser à élargir et non à réduire la base des responsables de la
> maintenance à long terme.
>
> Inversement, je comprends parfaitement les cartographes qui se méfient
> des changements soudains dans le rendu ou l'accès aux tags dans les
> logiciels d'édition. Beaucoup de gens apprécieraient probablement de
> mieux comprendre ce qui se passe sur le chemin d'une discussion
> d'attributs à un changement final dans le logiciel de rendu ou
> d'édition. Ces processus ne sont pas secrets, mais souvent mal documentés.
>
> Là encore, les différents canaux de discussion et le manque de flux
> d'informations entre cettes contribuent à la mauvaise humeur. Pire
> encore, le rapport entre les activistes et les canaux signifie que des
> personnes 

[OSM-talk-fr] Hydrographie : intégrer les aménagements artificiels aux rivières

[François Lacombe]

Salut à tous

Une question que je ne me suis peut-être pas assez posée : les relations de
rivières peuvent-elles prendre comme membre tout ouvrage de dérivation
artificiel ?

Dans le cas d'une centrale hydroélectrique, l'eau peut transiter par des
galeries sur des km, l'eau étant prélevée en amont et restituée plus bas.
Ces ouvrages font transiter énormément d'eau, la majeure partie. Le débit
restant dans la rivière en aval des barrages est appelé le débit réservé et
peut parfois être très réduit.

Il me semble difficile d'envisager la rivière sans ces ouvrages puisqu'ils
dérivent une majeure partie du débit parfois.
Voici ce que ça peut donner en Isère sur l'eau d'Olle, utilisée par EDF
pour la centrale de Grand-Maison
https://www.openstreetmap.org/relation/1749757

Les ouvrages hydrauliques sont ajoutés avec le rôle side_stream
Est-ce une valeur qui semble correcte ?
Le wiki n'est pas très explicite, ce sera peut-être l'occasion de le
clarifier (mais je suis peut-etre passé à côté de quelque chose).

Attention, il y a aussi d'autres relations pour les centrales :
https://www.openstreetmap.org/relation/3113489
Mais il n'en est pas question ici (voyez les différences entre les deux
relations)

Merci par avance pour vos avis, bonne soirée

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

Re: [OSM-talk-fr] Hydrographie : intégrer les aménagements artificiels aux rivières

[François Lacombe]

Bonjour à vous deux et merci pour vos réponses.

Il y a dilemme entre ces deux hypothèses :
1. La relation sert à modéliser une rivière naturelle : une déviation n'en
fait pas partie
2. La relation sert à modéliser l'écoulement de l'eau comprenant les
déviation du cours d'eau naturel. Là je me dit que quelqu'un pourrait être
intéressé pour retrouver uniquement le cours d'eau naturel. Après réflexion
on ne fait pas ça avec le rôle, mais directement avec les valeurs de
waterway qui distinguent explicitement cours d'eau naturels et artificiels.
=> Je me dis que la 2nde solution inclus la 1ere.

Le ven. 27 sept. 2019 à 16:52, Jérôme Amagat  a
écrit :

> On met en side_stream aussi les conduites qui font rivière -> station de
> pompage -> château d'eau -> habitations -> station d'épuration -> rivière ?
> :)
>
Dans le cas de centrales au fil de l'eau, l'eau n'est pas stockées. Si il y
a un lac entre les deux (ou un château d'eau), on est plus dans le cours
d'eau.


> Pour moi une rivière est lié à son lit (il faut bien sur que de l'eau
> continue à y couler :) ), ce n'est pas toute l'eau qui coule d'un point A à
> un point B.
>
Ok, cela s'entend, donc plutôt la 1ere configuration ci-dessus.

D'ailleurs la relation évoquée par François a comme tag waterway = stream
> et name = L'Eau d'Olle, ces même tags apparaissent sur les way du lit de la
> rivière mais pas sur les ways de la dérivation et personne n'aurait l'idée
> de les y mettre.
>
Pour le coup c'est un problème.
Que se passe-t-il si le cours d'eau en question mêle des tronçons avec
stream et river ?

Cet exemple, déviation d'une partie de l'eau d'une rivière sur plusieurs
> kilomètres ressemble au cas où un canal a été creusé en parallèle d'une
> rivière, pour la navigation, pour amené l'eau à une centrale électrique ou
> pour l'irrigation. Est ce que ces canaux font parti de la rivière ?
>
Oui, c'est la question  à laquelle je n'ai pas la réponse.
Est-ce que quelqu'un sais ce que dit le Sandre ?

Ce pose aussi le problème pour des dérivations beaucoup plus courtes dans
> le cas de barrages, de centrales électrique au milieu d'un court d'eau ou
> d’écluses, que faire ? est ce qu'il faut laisser un way qui traverse le
> barrage pour avoir une continuité de la rivière alors que l'eau n’emprunte
> pas ce chemin ? ou mettre dans la relation les way passant par les turbines
> de la centrale électrique ou dans les écluses et faut il mettre le nom de
> la rivière sur ces way ?
>
Là dessus je ne suis pas assez assidu mais en théorie je dirait oui pour
les turbines, plutôt non pour le nom de la rivière dans l'écluse.


> J'en profite pour parler de l'autre relation :
> https://www.openstreetmap.org/relation/3113489
> Relation avec type = site, power = plant, plant:output:electricity=*.
> power=plant avec plant:output:electricity=* donc c'est une centrale
> électrique et, pour moi, la centrale électrique, elle a une position bien
> précise, c'est là où il y a les turbines.
>
Non, il s'agit de l'aménagement complet. La documentation de type=site en
parle
https://wiki.openstreetmap.org/wiki/Relation:site
https://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Site#why_not_just_use_multipolygon.3F

Voir le rendu que fait OpenInfraMap à leur sujet. Possible sans relation ?
https://openinframap.org/#12.26/45.22671/6.42489

Pour les parc éolien je comprend l'utilisation des relations type=site, les
> éolienne sont la plupart du temps représenté par un node et tout ce qui a
> autour, c'est des champs ou de la forêt donc rien à voir avec la production
> d’électricité donc impossible de faire un polygone qui comprend tout ou de
> mettre toutes les éolienne dans un multipolygon.
> Pour une centrale hydroélectrique il faut tout ça (lac de barrage conduite
> ...) pour avoir de l'électricité mais je ne vois pas d'autre chose dans osm
> où l'on regroupe tant de chose dans une relation fourre-tout a part les
> relations public_transport=stop_area mais dans ce cas il y a quand même des
> tags pour l'arrêt physique.
>
Ne serait-ce parce qu'on voit autant indiqué "Centrale de machin chose" sur
le bâtiment abritant les turbines que sur le barrage. C'est donc le même
aménagement.
Il pourrait être possible de procéder avec la topologie : de la turbine
présente dans le bâtiment identifié comme la centrale, on remonte les
waterways pour tomber sur un nœud contenu par un lac lui-même créé par un
barrage ou tomber sur un cours d'eau naturel.
C'est un bon usage pour une base de graphe, que nous n'avons pas encore
dans l'écosystème. Donc comment on relie les prises d'eau (parfois
plusieurs dizaines à des km de distance) aux générateurs ?
Dans l'immédiat, le meilleur moyen pour représenter l'aménagement, c'est
type=site.

Bonne soirée

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

Re: [OSM-talk-fr] Proposition - RFC - Armement des supports de lignes aériennes

[François Lacombe]

Salut à tous,

Relativement à cette proposition, les premières valeurs de line_attachment
ont fait leur apparition sur taginfo
Au Sénégal dernièrement, dans un quartier de Dakar et le principe semble
avoir été approprié.
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Lines_attachements

Avant de lancer le vote, serais-ce possible à certains d'entre vous, en
France ou ailleurs, de regarder autour de chez eux à la recherche de
poteaux ou autres supports et de voir si ils arrivent à traduire ce qu'ils
voient avec la documentation proposée svp ?
Je pense que de cette manière on se prémunira au maximum de situations non
prévues dès le départ.

Merci à vous par avance et bon weekend

François

Le jeu. 13 juin 2019 à 23:25, François Lacombe 
a écrit :

> Salut à tous,
>
> En chemin pour le SOTM, pourquoi ne pas traduire une super proposition
> wiki en cours ?
> https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Lines_attachements
>
> Celle-ci concerne, sous un nom un peu barbare, la manière dont les lignes
> (électriques mais pas que) sont attachées à leur support.
> C'est une proposition "de service", servant à décharger la clé tower:type
> de valeurs particulières puisque cette clé dépasse largement le seul
> contexte de l'énergie ou de l'ancrage au support (on s'en sert pour
> distinguer les tours de télécommunication des tours de chateaux...)
> La clé line_attachement permet de décrire quelque chose d'assez visible
> quand on a le défaut de regarder tous les poteaux qui passent.
> Elle donne en outre encore plus de valeur aux données relatives aux
> pylônes, poteaux et autres supports.
>
> S'est engagée depuis l'année dernière une discussion qui a amené pas mal
> de maturation sur la version anglaise, il était maintenant possible de la
> traduire pour le français en vue de la voter
>
> Vous pouvez en prendre connaissance et me remonter vos observations si
> vous en avez.
>
> Bonne fin de semaine
>
> François
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition de modification en masse - Suppression de ref:INSEE des noeuds "place"

[François Lacombe]

Bonjour Stéphane

Je suis d'accord avec cette proposition.

Bon weekend

François

Le sam. 16 nov. 2019 à 09:51, Stéphane Péneau 
a écrit :

> Salut,
>
> Suite aux discussions précédentes  [1], je propose de supprimer les tags
> ref:INSEE présents sur les noeuds "place" en France.
>
> Cette requête overpass donne 37042 noeuds avec ce tag :
> http://overpass-turbo.eu/s/O8N
>
> J'ai regardé une partie des noeuds des territoires d'outre-mer, et ils
> font partie d'une relation admin, donc il n'y a à priori pas de problème
> à les supprimer.
>
> En France métropolitaine, toutes les relations existent aussi.
>
> L'opération serait donc relativement simple :
> - Requête overpass ci-dessus
> - Ouverture du résultat dans Josm
> - Suppression du tag ref:INSEE
> - Envoi du changeset vers les serveurs.
>
> Si vous voyez des cas particuliers, c'est le moment d'intervenir.
>
> Stf
>
> [1]
> https://lists.openstreetmap.org/pipermail/talk-fr/2019-October/094600.html
>
>
> ___
> 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] Mirepoix sur Tarn, les ponts... et OSM

[François Lacombe]

Salut à tous,

Un triste événement nous a rappelé ce matin le rapport rendu en juillet par
le sénateur Maurey sur la sécurité des ponts.
http://www.leparisien.fr/faits-divers/toulouse-un-pont-s-effondre-a-mirepoix-sur-tarn-au-moins-un-mort-18-11-2019-8195481.php

Le même sénateur a commenté brièvement ce matin en rappelant que la
connaissance des ponts, en particulier des 29 000 qui poseraient problème
devait être pris au sérieux.
Bien qu'ici ce soit une négligence qui puisse être à l'origine du drame,
serions-nous les seuls à produire un inventaire exhaustif des ouvrages que
peu de monde ne semble maîtriser en totalité ?

La multiplicité des exploitants ne permet pas d'en avoir une vue
consolidée. C'est un peu gênant pour faire des études voire capitaliser sur
les inspections faites. OSM peut ici encore apporter sa pierre à l'édifice.

Bizarrement j'essaie de sortir tous les ponts de France mais même Overpass
pense qu'il y en a trop : http://overpass-turbo.eu/s/Oco

Quelqu'un aurait une idée pour améliorer cette requête ?

Bonne soirée

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

Re: [OSM-talk-fr] Mirepoix sur Tarn, les ponts... et OSM

[François Lacombe]

Merci pour vos réponses, c'est top :)

J'essaierai bien d'écrire un petit quelque chose sur le sujet, puisqu'OSM a
une valeur ajoutée dans l'inventaire que personne n'est capable de faire.

On lit par endroit qu'en dessous de 2m c'est plus un passage busé qu'un
pont, mais ça reste un ouvrage d'art par rapport à une chaussée sur
plateforme en dur.
Le but serait d'avoir la hauteur de passage, la limite de poids admissible
pour passer dessus ainsi que la vitesse limite, pour avoir une bonne base
de travail et attirer l'attention des TDL et gestionnaires.

A+

François

Le lun. 18 nov. 2019 à 22:16, marc marc  a
écrit :

> Le 18.11.19 à 19:55, Yves P. a écrit :
> > Overpass manque de mémoire. C’est sur ma bécane (j’ai pleins d’onglets
> > ouverts…) ou c’est sur le serveur ?
> > /"runtime error: Query ran out of memory in \"query\" at line 13. It
> > would need at least 518 MB of RAM to continue."/
>
> sur le serveur
> ___
> 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] Lignes BT et HTA Was: Re: dégradation notable d'OSM

[François Lacombe]

Bonsoir Deuzeffe, JY, Julien,

Garder à l'esprit que pour l'instant Osmose ne fait pas de conflation
linéaire
On a déjà suffisamment à faire avec le ponctuel de toutes façons :)

Le dim. 8 déc. 2019 à 22:18, deuzeffe  a écrit :

> Le 06/12/2019 à 00:21, Julien Lepiller a écrit :
>
> > Je réagis sur les fonds rte. Il y en a qui sont utilisables pour
> > l'édition ? Parce que le sujet m'intéresse et que je pourrais aider à
> > compléter dans ce cas.
>

Oui, voir ici :
https://opendata.reseaux-energies.fr/explore/?sort=modified=RTE=Infrastructures
Osmose consomme déjà le fichier des pylônes.

Il est d'intérêt d'ajouter les lignes, avec la tension, operator=RTE et
cables=* si possible.


> Pour ma part, depuis qu'osmose me signale gentiment plein de poteaux
> sans ligne parce que j'y ai posé des transfo. (coucou François), comme
> JY, bien envie d'utiliser dans un premier temps ce genre de truc :
> https://data.enedis.fr/explore/dataset/reseau-bt/information/ (pleins
> d'export possible qu'on doit pouvoir faire manger à JOSM, je suppose).
>

La BT concerne les lignes entre le transformateur en haut du poteau et les
maisons.
Il y a aussi ça pour les lignes alimentant ces transformateurs :
https://data.enedis.fr/explore/dataset/reseau-hta/information/
Je vous recommande la HTA avant la BT. La BT est très capillaire, moins
visible sur les vues aériennes donc plus difficilement maintenable.


> Mais si je n'intègre que les lignes sans mettre tous les poteaux qui
> manquent (fainéante-mode), ça va pas l'faire, spa ?
>

Ca ne posera pas de problème de topologie dans OSM, ni d'erreur dans Osmose.
Les poteaux sont par contre une information de grande valeur en ce moment,
tout le monde se les arrache.
La légende raconte que Enedis n'a pas l'information dans son SIG. Ajouter
les poteaux donne de la visibilité à OSM auprès d'une communauté de
professionnels élargie en ce moment aux télécoms puisque les poteaux sont
convoités pour la fibre aussi.
Lorsque c'est pertinent, ajouter operator=Enedis double la valeur du point,
qualifier le matériau avec material=* la décuple.

Baladez-vous sur OpenInfraMap pour se rendre compte des efforts incroyables
consentis par certains, comme dans le Jura
https://openinframap.org/#14.44/46.74111/5.46428

Certaines régies numérotent les supports, il faut passer auprès de quelques
uns pour comprendre l'ordre et faire quelques séries
https://openinframap.org/#14.99/46.02592/6.17694

Pour info, il y a environ 16 millions de poteaux électriques en
distribution, 13 millions de poteaux téléphoniques en France.
Ce qui laisse encore quelques soirées à occuper.

Bonne journée

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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Bonsoir Marc,

Le dim. 15 déc. 2019 à 21:15, marc marc  a
écrit :

> Y a t il des objets ayant plus d'une ref ? Et si oui est-ce à ce point
> fréquent au point d'en faire la règle de base ?
>

Dans notre cas, tous les postes à la limite entre distribution et transport
électrique auront un ref:FR:gdo et un ref:FR:RTE
Il faut aussi distinguer ce qu'on voit sur le  terrain, et la référence qui
permet de joindre avec des référentiels externes.
Si tu lis P99 sur la commune d'Annecy, la bonne valeur sera 74010P0099
alors que ref gardera le P99.


> Café l'autre sujet où je me pose la question de l'inutilité de
> l'utilisation de namespace pour ref quand cela ne fait que dupliquer le tag
> operator
>

Avoir une clé dédiée pour ces refs permet d'appliquer des règles
particulières, par exemple sur le format des valeurs.
ref=* n'a pas de règles sur le format, compte tenu de sa généricité.

Ici ref:FR:gdo ne sera plus bijectif avec l'opérateur puisqu'on aura Enedis
et GRDF.

Bonne soirée

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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Salut à tous,

Je retiens donc ref:FR:gdo pour la nouvelle clé.
Une notice du changement est disponible ici
https://wiki.openstreetmap.org/wiki/FR_talk:Key:ref:ERDF:gdo#Remplacement_par_ref:FR:gdo

Comme vous pouvez le voir, il y a pas mal de choses à vérifier. Ce sera
fait d'un seul coup, grâce à JOSM qui permet d'explorer facilement les
objets de chaque couche.

Il y a aussi une chapitre sur la reprise de la valeur de certains clés
comme ref ou name
Ceci peut par contre être fait au fil de l'eau, à votre convenance ou
affinité avec telle ou telle région.

Si il n'y a pas d'objections sur les opérations à réaliser, ceci sera fait
d'ici fin décembre et ref:ERDF:gdo migrée sur le wiki vers une nouvelle page

Bonne fin de weekend

François

Le lun. 9 déc. 2019 à 09:32, Yves P.  a écrit :

> @François
> > Ainsi ref:FR:gdo permettrait aussi de documenter les affleurant gaziers
> Plutôt celui-ci car effectivement il est utilisé sur les coffrets de gaz
> qui alimentent un client…
> Et comme ça, il n’y a plus de problème quand ERDF ou Enedis changeront
> encore de nom 
>
> @Donat
> > Une solution serait d'inventer une ref:operator:wikidata:Q=***
> ref:Q c’est plus simple. Ou plutôt ref:Pxxx ou Pxxx
> On va faire une PR pour qu’OSM affiche automatiquement le nom de la
> propriété dans la langue du contributeur, avec le lien automatique…
>
> En gros, on transfère tous les objets OSM dans le wikidata (d’OSM)
>
> —
> Yves
> ___
> 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] Idée folle : changer building=service en building=utility lorsqu'applicable

[François Lacombe]

Bonjour Stéphane

Le dim. 15 déc. 2019 à 11:35, Stéphane Péneau 
a écrit :

> Salut,
>
> building=* est censé donner des informations sur *le type de bâtiment*.
> J'ai l'impression que building=utility donne plus d'information sur ce
> qu'il y a à l'intérieur que sur le bâtiment en lui-même, non ?
> Tu peux me rétorquer qu'il en est un peu de même pour d'autres valeurs de
> building. Oui, tu peux :-)
>

La question clé est : qu'est-ce que le type de bâtiment ? Y en a-t-il qu'un
seul?
C'est pour cette raison que je n'aime pas employer "type" dans les tags.
Heureusement building:type est déprécié
https://wiki.openstreetmap.org/wiki/Key%3Abuilding%3Atype

On peut très bien chercher à classifier les bâtiment selon leur mode de
construction, structure, destination,...
Ce que je sais c'est que building=service ne nous dit pas de quel espèce de
service il s'agit.
Avec building=utility, on sera capable de fermer la chaîne sémantique avec
des enchaînements building=utility + utility=power + power=substation +
substation=minor_distribution
=> Avec une petite chaîne comme celle-ci on règle d'un coup et durablement
la gestion immobilière d'Enedis, la qualification des locaux pour la DGFip
et la consolidation du foncier pour les communes qui collectent des taxes
d'occupation du domaine public.

building=utility te renseigne uniquement sur la destination (comme
building=garage) sans te dire ce qu'il y a à l'intérieur.
Une station de pompage et un poste de transformation de quartier sont tous
les deux éligibles à building=service / building=utility, pourtant le
contenu et l'activité associée seront très différents
utility=power vs utility=water sont là pour apporter un début de
distinction par ailleurs.

Bonne fin de dimanche

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

[OSM-talk-fr] Fwd: [osm-grenoble] Projet Europeen de l'Eau/European Water Project - Introduction

[François Lacombe]

Bonsoir à tous,

Je relaye ici le message de Stuart qui a pris la peine de présenter ce
projet sur la liste local-grenoble.
Cela peut en intéresser certains

François

-- Forwarded message -
De : European Water Project 
Date: mar. 17 déc. 2019 à 10:57
Subject: [osm-grenoble] Projet Europeen de l'Eau/European Water Project -
Introduction
To: 


Bonjour,

Je m'appelle Stuart Rapoport. J'habite Divonne les Bain dans l'Ain.

Nous nous lançons dans un projet collaboratif qui est 100% Open Data et
utilise exclusiviement des données d'OpenStreetMap, Wikidata et Wikimedia
Commons. Notre toute nouvelle (et très petite) ONG Suisse  Projet Européen
de l'Eau (European Water Project) a but d'inciter les personnes de boire
l'eau du robinet et d’arrêter d’acheter des bouteilles à usage unique,
notamment celles en plastique.

J'ai écrit une Progressive Web Application en HTML5, CSS et Javascript que
vous pouvez télécharger sans passer par l'Apple Store ou le Google Store à
https://europeanwaterproject.org. Pour peupler les fontaines sur notre
carte, nous faisons tourner un script en nodejs qui extrait les données
d'OSM par l'API Overpass et  celles de Wikidata par l'API SPARQL.

Pour l'instant nous nous concentrons sur les fontaines d’eau potable en
Europe, mais nous voulons dans un deuxième temps participer dans le
développement d’un réseau de cafés et de restaurants qui sont d'accord pour
remplir des gourdes d'eau gratuitement pour toute personne qui le demande.

Nous présentons notre APP pour la première fois, le 8 janvier devant 860
étudiants de 48 pays.

Je voulais savoir si je pouvais venir le week-end du 15-16 février pendant
votre CA pour présenter rapidement notre projet ?

Je vous prie d'excuser mes fautes de français.

Cordialement,

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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Bonsoir Deuzeffe,

Le lun. 16 déc. 2019 à 21:59, deuzeffe  a écrit :

>
> Si ma voix a un quelconque poids, elle ne s'y oppose pas.
>

C'est au contraire tout ce qui me manquait pour passer à l'action
Le wiki a déjà la nouvelle page :
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:gdo

Le déplacement aura lieu d'ici fin décembre

Bonne soirée

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

Re: [OSM-talk-fr] Idée folle : changer building=service en building=utility lorsqu'applicable

[François Lacombe]

Bonsoir Jérôme,

Le lun. 16 déc. 2019 à 01:34, Jérôme Amagat  a
écrit :

>
> C'est joli mais qu'est ce que ça apporte de plus comme info que
> building=service + power=substation + substation=minor_distribution ?
>

Avec building=service, on se sais pas de quel service il peut s'agir.
Un garagiste c'est aussi un service finalement (on me l'a déjà sorti plein
de fois).

Il est réellement intéressant de pouvoir construire des chaînes comme ce
que je montrais dans le mail du dessus.
Si le consommateur est intéressé pour trouver tout le bâti impliqué dans
les utilités, il ne connaît peut-etre pas les valeurs plus spécifiques
comme power=substation et il peut en oublier.


>  L'architecture d'un garage est le plus souvent très éloigné de celle
> d'une maison, ou d'une église. Ce qui ressemble le plus à un garage c'est
> un autre garage, une grande porte, pas ou seulement des petites ouverture,
> bâtiment pas très haut, ils sont pas tous comme ça mais beaucoup. Pour
> building=service on peut faire la même chose, il y a sûrement plus de cas
> différents que pour le garage.
> Malgré ça je suis d'accord que ce que l'on met dans building=* donne plus
> d'info sur à quoi il sert que sur le bâtiment en lui même mais on demande
> par exemple de laissé building=church même si ça ne sert plus de lieu de
> culte et il faudrait laissé building=garage même si le bâtiment est devenu
> (sans trop de modif) une habitation...
>

Si on documente la destination d'un bâtiment, pourquoi devrait-on laisser
building=garage si celui-ci deviens une habitation?
Il y a bien des silos de lancement de missiles balistiques qui deviennent
des appartements, on voit de tout.


> Si j'en reviens au problème de départ :) , rien n’empêche d'indiquer avec
> un autre tag à quoi sert ce bâtiment et pourquoi pas avec utility=*, on
> peut déjà le faire avec d'autres tags, par exemple, une église convertie en
> musée c'est building=church + tourism=museum il n'y a pas besoin de
> building=tourism ou autre chose.
> On peut privilégié une valeur comme building=utility lorsque le bâtiment a
> été construit à cet effet mais je pense que building=service a l'avantage
> d'être plus simple à comprendre et est déjà beaucoup utilisé.
>

Il est beaucoup utilisé, ce qui posera sûrement problème, mais facile à
comprendre, non
Service ça veut tout et rien dire, vraiment.
D'ailleurs le bâtiment qui stocke le sel pour le déneigement des routes à
côté de chez moi, c'est building=service ou pas ? (parce que c'est pas une
"utility" mais les véhicules garés devant sont tous stickés "SERVICE").
Même si le wiki semble utiliser building=service pour building=utility, je
ne suis pas sûr en plus que toutes les occurrences soient concernées par le
changement proposé. Certains bâtiments ne doivent pas être des sites
techniques d'utilités à proprement parler.

Bref, il y a besoin d'en discuter encore un peu

Bonne soirée

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] Idée folle : changer building=service en building=utility lorsqu'applicable

[François Lacombe]

Le mer. 18 déc. 2019 à 02:06, Jérôme Amagat  a
écrit :

>
> Donc si on suis cette logique, il faut changer en building=tourism tous
> les hôtels, en building=amenity tous les restaurants, lieu de culte, bar,
> école... pour avoir une belle chaîne de tag.
>

Uniquement si le bâtiment est complètement dédié à ces destinations, en
tout cas pour ce qui nous intéresse ici.
Que ce principe ne soit pas en vigueur partout, c'est en partie à cause de
l'historique (particulièrement marqué sur building) et aussi parce que
certains concepts ne sont pas aussi liés que la destination d'un bâtiment
aux équipements qu'il héberge.

OSM est une base sémantique, chaîner les concepts me semble être une
pratique vertueuse.
Utiliser deux termes, service sur building et utility ensuite, pour la même
chose n'est pas bon non plus (et on ne redéfinira pas service=* pour ça)


> On le laisse comme on laisse building=church sur une église reconverti en
> musée, habitation...
> C'est la plupart du temps la destination première du bâtiment que l'on met
> dans building=* mais si l'utilisation change le tag building=* ne doit pas
> changer.
>

Ce qui rend la signification de building=* moins claire que ce je
pensais... c'est la destination, puis la forme, on ne sais pas bien.
La première destination d'un bâtiment remonte à autant qu'on puisse se
souvenir... c'est plutôt pas clair.


> Il est beaucoup utilisé, ce qui posera sûrement problème, mais facile à
>> comprendre, non
>> Service ça veut tout et rien dire, vraiment.
>>
>
> C'st plus facile à comprendre que "utility" !
>

Question d'appréciation, je ne sais toujours pas ce que veux dire service
(intrinsèquement, sinon j'ai bien lu le wiki). Qu'est-ce que tu comprends ?
Par contre utility, on a une définition et un périmètre clairs, au moins
pour les pays développés : https://en.wikipedia.org/wiki/Public_utility


> D'ailleurs le bâtiment qui stocke le sel pour le déneigement des routes à
>> côté de chez moi, c'est building=service ou pas ? (parce que c'est pas une
>> "utility" mais les véhicules garés devant sont tous stickés "SERVICE").
>>
>
> Je dirais que si le bâtiment a été construit pour le stockage c'est plutôt
> building=warehouse.
>

D'accord avec ça

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

Re: [OSM-talk-fr] OSM hack-weekend à Karlsruhe

[François Lacombe]

Bonjour Christine,

Je m'associe au propos, pour avoir participé à l'édition d'octobre dernier
: c'est génial

Ce weekend là, OSM France organise son conseil d'administration physique à
Grenoble
Ca sera difficile pour moi d'être avec vous

A bientôt !
François

Le mer. 11 déc. 2019 à 12:04, Christine Karch  a
écrit :

> Bonjour,
>
> Karlsruhe n'est pas loin avec le TGV/OUI de Paris. J'aimerais bien vous
> inviter pour le prochain OSM hack week-end chez nous:
>
> https://wiki.openstreetmap.org/wiki/Karlsruhe_Hack_Weekend_February_2020
>
> On parle l'allemand, mais bien sûr aussi un peu l'anglais et le
> français. Vous êtes invités de participer :)
>
> Christine
>
> ___
> 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] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Salut à tous,

La motivation de Stéphane sur ref:INSEE m'a motivé pour proposer un autre
changement sur une clé de référence.
Il sera pour ma part moins important en volume concerné. Il porterait sur
le remplacement automatique de ref:ERDF:gdo en ref:FR:Enedis ou ref:FR:gdo
sur 2700 objets.
https://wiki.openstreetmap.org/wiki/FR:Key:ref:ERDF:gdo

La justification est de deux ordres :
- ERDF n'existe plus
- La référence est propre à la France et ne comporte pas FR. Je trouve que
ce serait une bonne chose
=> ref:FR:Enedis pourrait convenir

Nous utilisons ref:ERDF:gdo pour documenter les réseaux électriques mais le
Guide Des Ouvrages est partagé avec les gaziers de GRDF.
Ainsi ref:FR:gdo permettrait aussi de documenter les affleurant gaziers

N'hésitez pas à donner votre avis sur cette proposition, en tenant compte
de la volumétrie d'usage :
https://taginfo.openstreetmap.org/keys/?key=ref%3AERDF%3Agdo

Ce peut aussi être l'occasion de nettoyer un peu les données, parce que
beaucoup de ces refs sont aussi dans ref=* et pas dans ref:ERDF:gdo
actuellement.

Bonne après-midi

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

[OSM-talk-fr] Idée folle : changer building=service en building=utility lorsqu'applicable

[François Lacombe]

Salut à tous,

En faisant un peu le point sur le potentiel de la nouvelle clé utility=* et
sa sémantique, elle est généralisable à beaucoup d'objets sans trop
d'efforts (principalement les bâtiments et les street cabinet)
Elle traduit l'activité attachée à un bâtiment ou site pour l'acheminement
en énergie ou fluides en tous gens (en référence aux utilités publiques)
https://wiki.openstreetmap.org/wiki/FR:Key:utility

Je verrai bien une nouvelle valeur à building, building=utility (+
utility=*) qui aurait du sens.

Mais il y a déjà une valeur building=service, sans qu'on sache finalement
de quel service il s'agisse. On est d'ailleurs pas sûr que ce soit
restreint aux utilités, même si la documentation y fait beaucoup penser.
https://wiki.openstreetmap.org/wiki/Tag:building%3Dservice

Il y a certainement une partie de building=yes et building=industrial qui
seraient concernés aussi.

Que penseriez-vous d'introduire building=utility, remplacer
building=service quand c'est nécessaire et utiliser utility=* jusque là
pensé pour le bornage ?

Il y aura une proposition en bonne et due forme mais cela ne nous empêche
pas d'en discuter pour la France pour commencer.

Bonne soirée

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

Re: [OSM-talk-fr] [Tagging-fr] Proposition - Vote - Points de distribution telecom

[François Lacombe]

Bonjour Xavier,

Après t'être connecté sur wiki, rends-toi sur la version anglaise, au
chpitre du vote en bas de page et clique sur "Modifier le wikicode"
Lien direct :
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Telecom_distribution_points=edit=7

Esuite au bas de la liste, ajoute {{vote|yes}} -- ou {{vote|no}} --
selon ton avis sur le sujet
Et cliques sur sauvegarder

C'est tout !

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>


Le mar. 10 déc. 2019 à 19:25, XavierBizot22440 
a écrit :

> Bonjour,
>
> Comment fait-on pour voter ?
>
> Je n’ai pas saisi, comment le faire… malgré l’explication faite sur la
> page… il y a de cela quelques semaines, où j’avais voulu participer à un
> vote depuis un article dans la newsletter, mais….
>
> Quelque fois je pense être limité derrière mon clavier :)) Alors soyez
> indulgent s’il vous plaît.
>
> Merci
>
> Xavier
>
> Le 10 déc. 2019 à 19:19, François Lacombe  a
> écrit :
>
> Salut à tous,
>
> Je pensais avoir envoyé ce mail plus tôt et il est resté en brouillon...
> Pour la 4ième et dernière proposition de cette année, je me suis intéressé
> aux points de distribution télécoms.
> Ces petites boites que tout le monde a au moins vu une fois mais tellement
> nombreuses qu'on fini par les ignorer complètement.
>
> https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Telecom_distribution_points
>
> Le vote est désormais ouvert au bas de la version anglaise
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_distribution_points
>
> Garder à l'esprit que cette proposition ne prévoit pas de vous forcer à
> décrire les ~7 millions de points existant en France mais pose bien la
> question de la pertinence du tag.
> J'ai testé ça autour de chez moi et cela n'a pas posé de problème
> particulier.
>
> Les références inscrites sur ces boites peuvent être prises comme point de
> repère au même titre que les numéros d'adresse sur les façades.
>
> Merci par avance à ceux qui donneront leur avis et bonne soirée
>
> François
> ___
> Tagging-fr mailing list
> tagging...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging-fr
>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Proposition - Vote - Points de distribution telecom

[François Lacombe]

Salut à tous,

Je pensais avoir envoyé ce mail plus tôt et il est resté en brouillon...
Pour la 4ième et dernière proposition de cette année, je me suis intéressé
aux points de distribution télécoms.
Ces petites boites que tout le monde a au moins vu une fois mais tellement
nombreuses qu'on fini par les ignorer complètement.
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Telecom_distribution_points

Le vote est désormais ouvert au bas de la version anglaise
https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_distribution_points

Garder à l'esprit que cette proposition ne prévoit pas de vous forcer à
décrire les ~7 millions de points existant en France mais pose bien la
question de la pertinence du tag.
J'ai testé ça autour de chez moi et cela n'a pas posé de problème
particulier.

Les références inscrites sur ces boites peuvent être prises comme point de
repère au même titre que les numéros d'adresse sur les façades.

Merci par avance à ceux qui donneront leur avis et bonne soirée

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

Re: [OSM-talk-fr] Proposition - Vote - Points de distribution telecom

[François Lacombe]

Bonjour Cyrille,

distribution_box est moins adapté, parce que ce n'est pas toujours une
boite (on appelle ça des pieuvres lorsque c'est souterrain par exemple).
En français c'est "Point de concentration".

La proposition s’appelle "Distribution pointS", mais l'objet OSM est au
singulier parce que chaque objet doit avoir son point sur OSM :)

François

Le mar. 10 déc. 2019 à 19:37, Cyrille37 OSM  a
écrit :

> Le 10/12/2019 à 19:19, François Lacombe a écrit :
> > Le vote est désormais ouvert au bas de la version anglaise
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_distribution_points
>
> Il y a proposition de tagger "distribution_box" au lieu de
> "distribution_point"... Puisque c'est une petite "boite" dont il est
> question ;-)
>
> Aussi, la page se nomme "distribution_points" et dans le tableau Tagging
> il y a "distribution_point" ; c'est avec ou sans le "s" ?
>
> Cyrille37.
>
>
>
> ___
> 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] Les infrastructures et OpenStreetMap

[François Lacombe]

Salut à tous,

Il ne me semblait pas l'avoir partagé ici, une version plus succinte de la
prez donnée au dernier SOTM-fr à Montpellier est dispo.
https://www.dailymotion.com/video/x7lb289

Elle a été enregistrée lors de la 33ième réunion du FRnoG, le groupe
français des opérateurs de réseaux télécom.
Il y a donc une dominante plus forte accordée au métier, plus qu'à la
contribution comme cela avait été le cas à Montpellier.

C'était une bonne occasion de faire la promotion du projet OSM auprès de
professionnels consommateurs de SIG, avec quelques questions sympa à la fin.
Les slides :
https://www.slideshare.net/francoislacombe/cartographie-des-infrastructures-sur-openstreetmap-frnog-33

Prochaine étape sur le sujet lors du colloque semestriel de l'AVICCA
(Association des Villes et Collectivités Câblées) le 6 novembre prochain.
Un hackathon est prévu sur le sujet à Paris le 31/01 et 01/02/2020 à la
paillasse.
http://www.avicca.org/actualite/tdathack-territoires-data-et-telecoms

Bonne après-midi

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

Re: [OSM-talk-fr] Removed "WikiProject" prefix

[François Lacombe]

Bonsoir / Hi

Le project WikiProject_power_networks a été séparé en deux, l'un pour les
moyens de production, l'autre pour les réseaux.
https://wiki.openstreetmap.org/wiki/Power_networks
https://wiki.openstreetmap.org/wiki/Power_generation

Le prefixe WikiProject a été supprimé des pages locales également.
Il n'y a normalement plus rien qui me concerne sinon continuer de compléter
la doc de ces projets

Bonne soirée

--
WikiProject_power_networs has been split in two tonight. The first for the
generation facilities and the second for networks
https://wiki.openstreetmap.org/wiki/Power_generation
https://wiki.openstreetmap.org/wiki/Power_networks

WikiProject prefix is now completely absent from French projects
I'll be keeping documenting those local projects in the coming weeks

All the best

François

Le mar. 10 sept. 2019 à 21:39, François Lacombe 
a écrit :

> Bonsoir / Hi
>
> La page Télécoms vient d'être renommée, ainsi que le sous-projet français
> https://wiki.openstreetmap.org/wiki/Telecoms
> https://wiki.openstreetmap.org/wiki/Telecoms/France
>
> --
> i've just moved Telecoms project
> https://wiki.openstreetmap.org/wiki/Telecoms
>
> French subpage also
> https://wiki.openstreetmap.org/wiki/Telecoms/France
>
>
> All the best
>
> François
>
> Le ven. 6 sept. 2019 à 00:08, François Lacombe 
> a écrit :
>
>> Bonsoir / Hi
>>
>> Le mer. 4 sept. 2019 à 11:55, dcapillae  a écrit :
>>
>>>
>>> WikiProject Power networks/France
>>>
>>
>> Pour celui-ci, je m'en charge.
>> Préalablement, j'ai proposé une séparation de ce projet en deux : l'un
>> pour la production d'électricité, l'autre pour les réseaux la transportant.
>> D'ici une dizaine de jours, si il n'y a pas d'objection explicite,
>> j'opérerai la séparation pour toutes les langues, en ne reportant pas le
>> WikiProject.
>>
>> --
>> This one is my business
>> Before any removal of WikiProject, I prefered propose a split between two
>> topics : power generation and power transmission.
>> If there is no objection until 10 days, I'll do that split without using
>> Wikiproject prefix in new pages names.
>>
>> Bonne soirée
>>
>> François
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Proposition - Vote - Les bornes

[François Lacombe]

Salut à tous

Le vote est désormais lancé sur la proposition sur les bornes.
Plusieurs changements ont conduit au formalisme actuel que j'ai testé ce
mois-ci sans observer de problèmes majeurs.
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Utility_markers_proposal

Comme le titre l'indique, il est proposé d'ajouter deux nouvelles clés,
utility=* et marker=* pour décrire plus de bornes que pipeline=marker ne
pourrait le permettre.
L'accent est mis sur l'aspect visuel des bornes ainsi que l'activité à
laquelle qu'elles concernent.

La dépréciation de pipeline=marker est maintenue, pour libérer cette clé
d'une valeur qui ne concerne pas directement le fonctionnement des
canalisations (une borne est placée à côté, rarement directement dessus et
n'interfère pas dans l'écoulement du fluide par exemple). On évite aussi de
devoir définir power=marker et telecom=marker.
https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal

Merci par avance de donnée votre avis au bas de la page anglaise

Bon weekend

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

[OSM-talk-fr] Nouvelles données ouvertes sur les réseaux électriques

[François Lacombe]

Bonjour à tous,

Vous le savez, cela fait maintenant plus d'un an que je m’investis
activement pour motiver les 130 gestionnaires de réseaux de distribution
électrique à ouvrir la cartographie de leurs réseaux.
https://teamopendata.org/t/les-gestionnaires-de-distribution-electrique/1018

Suite aux deux avis CADA reçus favorables en septembre, les choses se
débloquent et les échanges sont de plus en plus nombreux avec les acteurs
concernés.

L'une des plus grosses société contactée, Gérédis dans les Deux-Sevres, a
libéré récemment la cartographie de son réseau, présumée sous licence
ouverte.
https://www.geredis.fr/Open-data

On y trouve le réseau aérien comme souterrain, ce qui est une bonne
nouvelle au vu du périmètre concerné, plus de 250 communes.

Ce n'est pas tout :
Enedis nous fait également le plaisir de compléter la cartographie déjà
libre depuis avril 2018 avec son réseau souterrain. Ceci sur l'ensemble de
la métropole, sois plus de 400 000 km de réseau portant le total à plus d'1
million de km avec l'aérien.
Le jeu de données des postes est plus complet qu'avant, avec l'ajout des
installations non visibles (la plupart des postes parisiens par exemple).
https://data.enedis.fr/explore/dataset/reseau-souterrain-hta/map/?location=15,45.14656,1.49646=jawg.streets

De ma compréhension et c'est à souligner, de nombreux mois de travail
semblent avoir été nécessaires pour élaborer ces jeux de données avec
l'investissement de plusieurs équipes.
Cela renforce encore la pertinence d'inciter les entreprises à ouvrir leurs
données, si cela était encore à démontrer. Le sujet intéresse et est utile
aux structures qui publient.

L'effort devrait se poursuivre en 2020 avec l'établissement d'un standard
(j'espère), nécessaire pour accompagner les plus petites structures vers
l'ouverture et harmoniser les licences choisies.
Et pourquoi pas quelques services, si il reste du temps.

Ceci ne serait pas probablement pas possible si la communauté ne
contribuait pas aussi assidûment sur le sujet. Les acteurs concernés ont
bien pris la mesure de notre engagement et de ce que nous pouvions apporter
au pot commun. Ces progrès sont à mettre au crédit de nos efforts à tous.

Bonne fin de semaine

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

Re: [OSM-talk-fr] Nouvelles données ouvertes sur les réseaux électriques

[François Lacombe]

Bonjour et merci à vous deux


Le ven. 20 déc. 2019 à 19:05, deuzeffe  a écrit :

>
> Sitôt un succès remporté, un autre en ligne de mire : bravo pour ta
> ténacité !
> (non, je n'ai pas dit que tu avais des gènes bretons au contraire de moi
> ^^)
>

Je n'ai pas écrit de roamap, mais la stratégie est claire dans les grandes
lignes depuis des années.
Côté gênes, c'est plutôt les montagnes du sud-ouest et des Alpes, n'en
déplaise aux Mont d'Arrée :)

Le sam. 21 déc. 2019 à 11:09, David Marchal  a écrit :

> Le réseau souterrain d’Enedis ? Vrai ? Effectivement, excellente nouvelle
> ; bien joué !
>

Celui-là même, vrai de vrai
Ainsi que celui de Gérédis, et les autres qui vont suivre dans des
échéances plus ou moins longues

Ce qui va permettre de lever un certains nombre de cas non solutionnés
depuis quelques temps
https://twitter.com/InfosReseaux/status/1208393271921315840?s=20

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

[OSM-talk-fr] Opportunité de promouvoir OSM : Démonstration T'dat'hack les 31/01 et 01/02

[François Lacombe]

Bonsoir à tous,

L'Association des Villes et Collectivités Câblées (AVICCA) organise sur
deux jours, les 31/01 et 01/02, un hackathon un peu particulier à La
Paillasse à Paris à destination de ses membres.
http://www.avicca.org/actualite/tdathack-territoires-data-et-telecoms
http://www.avicca.org/content/tdathack

Plusieurs collectivités vont réfléchir aux meilleurs moyens de valoriser
les données disponibles selon 3 thèmes :
- La fibre pour les entreprises
- Les couvertures Wifi municipales
- Le "new deal mobile" de résorption des zones blanches

Je participe à titre gracieux aux réflexions autour des données
géographiques pour l'événement et c'est une opportunité supplémentaire de
faire rayonner OSM auprès d'élus et de collectivités.
Il est possible de contribuer sur place pour l'appui aux participants qui
eux devront produire un livrable. C'est surtout pour présenter le potentiel
d'OSM et ce que nous faisons. Nous sommes 4 à y aller normalement.

Sur les thèmes prévus, OSM a déjà certaines données intéressantes suite au
travail effectué sur Osmose pour l'intégration des sites radio ANFR et à la
chasse aux armoires cuivre et FTTH. Elles sont complémentaires à ce que les
professionnels du secteur peuvent partager, il y a de la place pour tout le
monde.
Il n'est pas nécessaire d'être familier avec ce domaine de contribution
pour venir assister les participants. La connaissance et la culture autour
d'OSM est ce qui est le plus recherché et nous avons ici une belle tribune
il me semble.

Pensez aussi aux contacts privilégiés qui peuvent être noués au cours de
ces rencontres.

N'hésitez pas à me contacter si cela vous tente de participer, à bientôt

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

Re: [OSM-talk-fr] Idée folle : changer building=service en building=utility lorsqu'applicable

[François Lacombe]

Bonsoir Marc,

Le mer. 18 déc. 2019 à 17:40, marc marc  a
écrit :

>
> il y a une erreur de signification : building=service décrit l'apparence
> "batiment dit de service", elle ne décrit pas qu'un service y a lieu,
> d'autres tags décrivent si quelques choses y a lieu (power, amenity, ..)
>

D'accord, partons sur l'affirmation que building=* concerne l'apparence du
bâtiment, cohérent avec ce que disais Jérôme plus haut. Peut-on mettre à
jour le wiki avec cette définition ?
A titre perso, je trouve que se rapporter à l'apparence est critiquable
puisque subjectif mais ça reste un avis individuel.

Sur le fait de conserver cette apparence sur building ne doit pas être
partagé par tous, je me souviens être passé à côté de ce bunker reconverti
en chambre d'hote :
https://www.google.fr/maps/@50.0665915,-5.6734547,3a,75y,171.31h,92.9t/data=!3m6!1e1!3m4!1sauKZG6rQhRkQIkKLGoE_Cg!2e0!7i13312!8i6656
https://www.openstreetmap.org/way/512685914
C'est un building=house, depuis sa création et un exemple au milieu de tout
le reste, j'en conviens.

Le terme building=service pour désigner les bâtiments techniques a été de
base mal choisi puisqu'il est pensé pour refléter "Les services d'utilités
publiques" qui se traduit comme "public utility" en anglais
"Public services" se sont les impôts ou l’hôpital public. Et évidemment,
nous n'allons pas utiliser building=service sur un hôpital.
Nous français nous le prenons avec son sens transparent alors que ce n'est
juste pas le bon terme, ce qui rend cette discussion compliquée entre nous
puisque "service" est un terme qui semble clair de prime abord, donc peu
contestable.
Nous devrions pour notre part parler de bâtiment technique.

> Il est réellement intéressant de pouvoir construire des chaînes comme ce
> > que je montrais dans le mail du dessus.
> > Si le consommateur est intéressé pour trouver tout le bâti impliqué dans
> > les utilités, il ne connaît peut-etre pas les valeurs plus spécifiques
> > comme power=substation et il peut en oublier.
>
> c'est peut-être un vrai problème mais changer de valeur building=* est
> une fausse solution
>


> un poste de transformation peux très bien se trouver dans un bâtiment
> dit de service, un bâtiment ayant l'apparence d'un garage, voir une
> pièce dans un centre commercial, ou une partie d'une pièce multi-fonction)
> chacun de ces cas aura un tag building/room différent.
>

Aurais-je dû dire "le bâti dédié aux utilités", parce que nous sommes
d'accord.
Des locaux techniques peuvent se trouver dans des immeubles d'habitation ou
de bureaux, mais ils ne sont pas concernés ici.
Pour vous donner tous les détails, les bâtiments complètement techniques
sont souvent propriété de la collectivité ou de l'exploitant. Un local
installé dans un immeuble ayant une autre destination fera l'objet d'une
servitude, c'est différent.

Est-ce que c'est le 1er critère pour définir une clé sur OSM?
Non, et je ne cherche pas rentrer dans cette complexité réglementaire, mais
c'est un élément qu'on peut avoir à l'esprit.


> si tu veux regrouper toute les utilités sous une même clef,
> la clef utility=* convient bien, sans qu'il soie nécessaire d'ouvrir
> la proposition quasi impossible à faire voter de changer
> building=service pour chainer les clefs/valeurs.
>

C'est bien pour ça que nous en discutons ici. Ca au moins le mérite de nous
faire réfléchir sur les définitions et je vous remercie pour vos
contributions.
J'ai retenu les arguments concernant building=service suivants :
- Pour
* Largement établi dans la base
* Transparent en français, apparemment conforme à l'apparence

- Contre
* Contre-sens en anglais, avec sa propre définition
* On va devoir expliquer à beaucoup de monde ce qu'est un "service" au sens
de building, puis basculer sur utility. En somme c'est incompréhensible,
deux termes pour parler de la même chose.


> si tu veux vraiement lier, building:use=utility et room=utility
>
Je le propose aussi pour améliorer building=*, parce que ça reviens dans
certaines discussions où des contributeurs sont perdus.
Ajouter une sous valeur en plus ne m'intéresse pas.

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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Bonsoir à vous

Le sujet doit être très clair, parce que je n'aurai pas fait une meilleure
réponse que celle de Yves.

En prenant en compte d'autres clés, il y a operator=* qui va permettre de
savoir chez qui aller taper.
operator=Enedis et operator=GRDF sont les deux seules valeurs possibles et
elles doivent être cohérentes avec les lettres utilisées dans la valeur et
éventuellement utility=* si applicable.

Bonne soirée

François

Le mer. 18 déc. 2019 à 13:13, Yves P.  a écrit :

>
> Je pensais qu'Yves, d'autant qu'il parlait de migrer l'info sémantique
> dans le wikidata OSM, aurait réagi.
>
> Je n’arrive pas à tout suivre ;)
>
> Actuellement avec une seule clé (ref:ERDF:gdo) on sait aller vers une base
> de données externe (gdo).
>
> Demain ref:FR:gdo pourrait être un lien vers un équipement électrique ou
> un équipement gazier.
>
> Donc vers deux bases différentes.
>
>
> Si on a deux bases il faut que quelque chose dans ref:ERDF:gdo, exprimable
> sous forme d'expression régulière permette de distinguer les différents
> cas. C'est probablement le cas mais je préfère que François confirme.
>
> Oui, ça peut se faire avec les lettres au milieu.
>
> Voici les valeurs que j'ai extraites de la base OSM avec une regex :
>
>- A
>- D
>- E
>- I
>- J
>- M
>- p
>- P
>- PN
>- PP
>- PS
>- R
>- S
>- Y
>
> Le wiki en détaille quelques unes :
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:ERDF:gdo
>
>- E remontées aéro-souterraines (RAS) : le wiki parle de EEM
>- J appareils de sectionnement HTA (IACM)
>- P poste de transformation électrique
>
> Sur le terrain, j’ai observé pour le gaz :
>
>- ROR robinet gaz réseau
>- RDP robinet gaz amont de poste réseau
>- DP poste gaz de distribution publique
>- CL poste de livraison gaz client
>
> —
> Yves
>
> PS:  Il y a quelques valeurs à nettoyer :
>
>- *
>- 01
>- BOURG n°354-1D202
>- ERDF
>- no
>- None
>- P4 KERIQUEL
>- P99 Kerguip
>- RR115P0018
>- RZ169 PROV JAGUER
>- SSGE7C2025
>- xxx
>
>
>- 15236P
>- 01105P105
>- 189J0011
>- 27203P053
>- 29233P00P76
>- J0291
>- J0294
>- J0295
>
> …
>
>
>
> ___
> 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] Nouvelles données ouvertes sur les réseaux électriques

[François Lacombe]

Bonjour et merci pour vos messages :)

Le ven. 20 déc. 2019 à 12:32, marc marc  a
écrit :

> tu veux parler des données contenu dans les base exportée ?
> oserions nous rêver d’attributs inspiré d'osm lorsque ceux-ci sont
> matures/bien choisit ? :)
>

Oui il s'agit bien de standardiser les données publiées.
Il y a 130 acteurs à harmoniser, à terme.
Si cela est possible et que je suis invité à y participer, j'essaierai
autant que faire se peut d'infuser un peu de culture OSM dans l'élaboration
de ce standard.

Cela facilitera d'autant l'intégration dans osmose et ailleurs, voire la
réutilisation directe avec d'autres outils.

Bonne soirée

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

Re: [OSM-talk-fr] Idée folle : changer building=service en building=utility lorsqu'applicable

[François Lacombe]

Bonjour Yves,

Le jeu. 19 déc. 2019 à 08:55, Yves P.  a écrit :

>
> @François
>
> building=service pour désigner les bâtiments techniques
>
>
> C’est pour moi la définition de ce type de bâtiment.
>

Oui, en français

Mais ca se traduit par "utilities" en anglais, pas par service. C'est mon
point sur la transparence faux ami de ce mot.
La terminologie OSM est en anglais.


> Si la définition en anglais ET l’usage posent problème aux non
> francophones, pourquoi pas.
> On pourra renommer cette clé et mettre à jour le wiki à leur demande.
>

C'est ce que je propose en faire en finalité.


>
> Concernant les chaines sémantiques, elles ont leur place dans une base
> sémantique.
> Ce n’est pas le cas de la base OSM, mais celui de wikidata ou de sa
> version OSM.
>
OSM est une base sémantisée depuis le début, conçue comme ça au départ.

Nous mettons seulement en place en ce moment les "DataItems", la couche
WIkidata pour la décrire, mais c'est bien le sujet
Je souhaite que ce soit l'un des sujets du prochain SOTM FR.


> On peut décrire ici qu’une armoire électrique est fabriquée par les
> humains, qu’elle contient des utilités (anglicisme ? ça se dit en français
> ?)…
> Qu’un code GDO est une référence, qu’elle ne s’applique qu’aux utilités
> gaz et électricité, en France…
>
> Franchement, j’ai du mal à étiqueter une armoire de coupure :
>
>- man_made=street_cabinet
>- street_cabinet=power
>- power=switch
>- voltage=2
>
> Et de mémoire, ce n’est pas l’exemple le plus long et pénible.
>
> En pratique la première clé ne sert à rien (elle n’est même pas utilisée
> pour le rendu).
>

Si si : c'est une armoire de rue.
C'est street_cabinet=* qui devrait être remplacé par utilty=* également,
mais ne mettons pas la charrue avant les bœufs.


> Par contre il faut se garder de faire une usine à gaz :
> On peut arriver à des choses trop compliquées qui génèrent des bugs ou des
> pratiques similaires à « taguer pour le rendu ».
>
C'est exactement ce qui guide ma proposition.

Le jeu. 19 déc. 2019 à 10:05, Yves P.  a écrit :

> Tu peux décrire (une fois pour toute) que power=switch n’est possible que
> pour street_cabinet=power ou power=pole…
> Et aussi (une fois pour toute) que les street_cabinet sont des
> sous-ensembles de man_made. Sans avoir besoin de le répéter à chaque objet
> dans la base OSM.
>

Non parce qu'il y a parfois des situations particulières que la flexibilité
des tags peut permettre de mieux adresser que la plupart des logiciels du
marché.

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

Re: [OSM-talk-fr] osmose ko

[François Lacombe]

Bon courage à vous
C'est que l'outil évolue et sera encore mieux après !

François

Le lun. 23 déc. 2019 à 16:01, marc marc  a
écrit :

> Bonjour,
>
> osmose est ko.
> info de freed :
> une grosse migration
> ça devait être sans coupure mais ça a coupé quand même
> ça va prendre plusieurs jours :/
>
> on regarde ce qu'on peux faire pour rétablir au + vite
>
> Cordialement,
> Marc
> ___
> 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] ref et ref:FR

[François Lacombe]

Bonjour

Des arguments sont toujours attendus pour faire autrement.

3 points :
* Qui sommes-nous pour affirmer que le nom de la ref ne collisionnera pas
ailleurs ?

* Le namespace permet de spécialiser la ref, d'y associer une documentation
complète et de séparer les concepts.
En ce qui me concerne, toutes les ref crées selon ce motif sont documentées
et vous serez bien inspirés non seulement de proposer cette documentation
sur une clé unique et aussi d'aller les valider dans les éditeurs

* Dans des cas de multi-ref (plus souvent le cas qu'on ne le pense), on
distingue clairement les différents concepts en jeu.
Avoir ref=* + ref:autre n'est pas acceptable à plusieurs titres : on
perdrait l'info de ce qui est effectivement lu sur le terrain (qui peut
contenir plusieurs champs)
Exemple : https://www.openstreetmap.org/relation/6668144

J'ai reporté ces arguments sur le wiki
https://wiki.openstreetmap.org/wiki/Talk:France/Liste_des_r%C3%A9f%C3%A9rences_nationales#Arguments_pour.2Fcontre_le_recours_aux_namespaces_locaux

Qu'il y ait des références mal définies, c'est vrai et du temps est
nécessaire pour les reformuler
De là à parler de dogme, c'est pas le cas n'est-ce pas ?

Bonne journée

François

Le mer. 12 févr. 2020 à 00:34, marc marc  a
écrit :

> on ets en plein dogme, cfr Réseau Arc en ciel de bus en france
>
> Le 12.02.20 à 00:21, François Lacombe a écrit :
> > En corollaire à ces propositions, je pensais suggérer à l'international
> > de ne laisser sur la page ref que les références mondiales
> > J'ai déjà supprimé le peu de ref:FR qui s'y trouvaient, en laissant
> > évidemment les liens vers la page française des références nationales.
> >
> > Cela permettra de clarifier les choses entre mondial/national et
> > d'inciter les pays à créer leurs propres page et namespace
> >
> > Penser qu'il y a aussi un niveau continental, avec quelques entrées en
> > Europe par exemple
> > https://wiki.openstreetmap.org/wiki/FR:Key:ref:EU:EVSE
> > https://wiki.openstreetmap.org/wiki/Key:ref:EU:ENTSOE_EIC
> >
> > Bonne soirée
> >
> > François
> >
> > Le mar. 11 févr. 2020 à 23:47, François Lacombe
> > mailto:fl.infosrese...@gmail.com>> a écrit :
> >
> > Bonsoir à vous
> >
> > +1 avec vous, bonne idée de séparer le tableau, pourquoi pas par
> > thèmes, comme nous le faisons pour les Map Features ?
> > Sur le caractère national/local, pourquoi pas ajouter une colonne
> > dans les tables pour le préciser ?
> >
> > Globalement, tout ce qui favorise l'adoption de ref:FR:* est bon à
> > prendre.
> >
> > François
> >
> > Le mar. 11 févr. 2020 à 18:57, deuzeffe  > <mailto:opensm@deuzeffe.org>> a écrit :
> >
> > Hello,
> >
> > Le 11/02/2020 à 18:25, leni a écrit :
> > > Bonjour
> > >
> > > En attendant que nous trouvions une meilleure solution pour
> > certaines
> > > ref:FR:*** , je pense qu'il serait bien de partager le tableau
> > de la
> > > page
> > >
> >
> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
> >
> > > (1) en deux parties :
> > > - une première partie avec les références qui s'appliquent sur
> > > l'ensemble du territoire (ref:FR:ARCEP=* ; ...) en y ajoutant
> > celles que
> > > j'ai trouvées dans le wiki (2)
> > > - une partie pour les autres (ref:FR:CRTA=*en Aquitaine ;
> > > ref:FR:BSPP:=* ; ref:FR:RATP=*) en y ajoutant celles que
> j'ai
> > > trouvées dans le wiki (3)
> > > - Faut-il y ajouter ref:FR:TransGironde et ref:FR:CUB qui sont
> > dans osm
> > > et que je n'ai pas trouvées dans le wiki ?
> > >
> > > Qu'en pensez-vous ?
> >
> > Sur le partage, que du bien. Et peut-être "l'ordonner" voire le
> > découper
> > par thème ?
> > Il me semble que j'en avais déjà parlé, sans grand succès...
> >
> > --
> > deuzeffe - qui n'a pas oublié la page transport à toiletter.
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org <mailto: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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Projet du mois de mars - #balanceTaBorne

[François Lacombe]

Hello

Merci Noémie pour la préparation !
Cela a été l'occasion de se poser quelques question sur les tags existant
et d'apporter quelques corrections mineures.

Les données issues de ce projet seront d'autant de bonne qualité que nous
nous rendrons sur le terrain à mon avis (quitte à utiliser Osmose pour
guider ses déplacements)

Je mettrai un tweet sur le sujet demain matin

Bonne fin de weekend

François

Le dim. 1 mars 2020 à 10:33, Noémie Lehuby via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Bonjour,
>
> Plus de 28 000 points de recharge pour véhicules électriques de recharge
> existent en France.
> Votre mission, si vous l’acceptez, est de cartographier toutes les bornes
> servant de support à ces points de recharge.
>
> Nous en avons déjà repéré environ 4 000, félicitations. Mais le compte n’y
> est pas !
>
> Vous l’aurez compris, il va s’agir d’une mission de terrain : ouvrons
> l’œil et n’en manquons aucune !
>
> Et comme pour chaque mission, nous pouvons nous appuyer sur ces précieux
> outils : MapContrib
> ,
> MapRoulette , Mapillary,
> Pic4Review , NotesReview
> ,
> etc.
>
> Le mot-dièse de cette mission est #balanceTaBorne. Pensez à l’indiquer
> dans vos changesets, vos notes OSM et vos communications sur les réseaux
> sociaux.
>
> Les détails plus précis de cette mission sont à retrouver sur la page de
> wiki
> 
> .
>
> Bonne chance !
>
> --
> Noémie Lehuby
> Jungle Bus - http://junglebus.io
>
> ___
> 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] Les actionneurs (portes automatiques, barrières, plots routiers, vannes)

[François Lacombe]

Hello

Relativement à ce vieux mail, j'ai commencé à renseigner quelques bornes
amovibles
https://www.openstreetmap.org/node/7216029508

Preneur de retours si quelqu'un a aussi tenté des choses
Il y a des portes sympa à décrire aussi :
https://wiki.openstreetmap.org/wiki/FR:Tag:actuator%3Dmanual

François

Le mar. 16 juil. 2019 à 00:02, François Lacombe 
a écrit :

> Salut à tous,
>
> J'ai récemment un peu avancé dans la traduction de la doc de la clé
> actuator=*, permettant d'indiquer la nature de l'actionneur mécanique
> mettant différents systèmes en mouvement.
> https://wiki.openstreetmap.org/wiki/FR:Key:actuator
>
> Cela va de la porte automatique, aux plots routiers amovibles en passant
> par les vannes (but initial de cet clé).
> La liste des valeurs possibles initiale est disponible sur la proposition
> votée en début d'année
>
> https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Pipeline_valves_proposal#Actionneurs
>
> Ce serait pas mal d'initier l'usage de la clé sur les dispositifs routiers
> de régulation de la circulation (barrières, plots, portails) et sur les
> portes automatiques, cela peut servir pour l'accessibilité.
> Seules les valeurs electric_motor, pneumatic_cylinder et
> hydraulic_cylinder devraient être utiles pour cela (on va laisser solenoid
> et thermostatic pour plus tard).
> https://wiki.openstreetmap.org/wiki/FR:Tag:actuator%3Delectric_motor
> https://wiki.openstreetmap.org/wiki/FR:Tag:actuator%3Dhydraulic_cylinder
> https://wiki.openstreetmap.org/wiki/FR:Tag:actuator%3Dpneumatic_cylinder
>
> Dans le cas de dispositifs manuels, la clé handle pourrait également servir
> https://wiki.openstreetmap.org/wiki/FR:Key:handle
>
> La liste des valeurs est aussi disponible sur la proposition (les valeurs
> n'étant pas toutes utilisées vu de taginfo, la liste ne les donne pas
> toutes)
>
> https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Pipeline_valves_proposal#Commande_manuelle
>
> Preneur de vos remarques pour ces cas d'usages, y compris indiquant des
> clés existantes plus particulières ou des cas non documentés.
>
> Bonne soirée
>
> François
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ajout de NRO : blocage d'un contributeur à envisager ?

[François Lacombe]

Salut à tous,

Eric est l'un des contributeurs les plus actifs sur les réseaux télécoms en
France
Je vais essayer de comprendre ce qu'il a essayer de faire. Nous échangeons
souvent sur Twitter, il n'est pour moi pas question de bloquer un
utilisateur comme lui.

Le sam. 25 janv. 2020 à 21:08, Romain MEHUT  a
écrit :

> Donc ce contributeur ajoute en grand nombre des "NRO". 1ère chose que je
> lui ai fait remarquer est qu'il n'y a pas lieu que ces objets aient un tag
> name.
>

Tous les noeuds de raccordement cuivre ont un nom d'usage, bien souvent le
nom du quartier desservi ou la ville concernée.
Par ailleurs, name=NRO c'est taguer pour le rendu certes. J'ai moi aussi
cette mauvaise habitude.


> 2ème chose, il a ajouté des NRO alors que préexistaient des objets
> man_made=telephone_office et telecom=central_office et ces tags sont
> aujourd'hui dépréciés cf.
> https://wiki.openstreetmap.org/wiki/Tag:telecom%3Dexchange Il
> conviendrait donc de reprendre les tags des objets existants plutôt qu'en
> ajouter des nouveaux.
>

Comme la doc le précise :
https://wiki.openstreetmap.org/wiki/FR:Tag:telecom%3Dexchange#Cas_de_multiples_noeuds_dans_le_m.C3.AAme_b.C3.A2timent
Lorsqu'il y a plusieurs medium desservis dans le même batiment, les noeuds
sont séparés.
Il a simplement créé le NRO sur un noeud dédié parce qu'il reste un NRA
cuivre dans le bâtiment.
Normalement il devrait y avoir deux noeuds mais il explique ne pas avoir
voulu toucher le polygone pour l'instant.

Le cuivre et la fibre vont cohabiter encore pour quelques années. Lorsque
le NRA cuivre disparaîtra, on supprimera le nœud dans toucher au NRO fibre.


> Et malgré mes remarques, il a continué à contribuer sans en tenir compte
> ex : https://www.openstreetmap.org/node/7156119118.
>

Ce site semble bien être mixte, sa contribution est la bonne.

Je sais que le sujet est technique et déroutant, mais il semble que les
pratiques soient bien adaptées ici.
Il faut en tenir compte.

Le sam. 25 janv. 2020 à 23:42, deuzeffe  a écrit :

>
> Va falloir faire une sacré ménage :(
>

Oui c'est bien ce qui se manifeste ici
https://wiki.openstreetmap.org/wiki/FR:Tag:telecom%3Dexchange#Possibles_erreurs

Mais le dernier modèle voté en 2018 est vraiment beaucoup mieux que le
précédent et ce ménage vaut le coup.

Bonne soirée

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

Re: [OSM-talk-fr] Ajout de NRO : blocage d'un contributeur à envisager ?

[François Lacombe]

Le dim. 26 janv. 2020 à 22:19, deuzeffe  a écrit :

>
> Cépabien ^^
> (dit celle qui ne taggue pas les name pour les points de distribution -
> j'ai bon ? - en building pour ne pas qu'ils soient rendus :P)
>

Les sous-répartiteurs cuivre et certaines armoires fibre peuvent aussi
avoir des noms d'usage.

Pour que tout le monde comprenne, on ne tague pas en building lorsque c'est
une armoire parce que man_made=street_cabinet et building=* sont
strictement incompatibles.
Aucun technicien ne peut physiquement rentrer dans une armoire, un bâtiment
si.
Les sous-répartitions comme les nœuds de raccordement peuvent
indépendamment être en bâtiment ou en armoire, mais jamais les deux en même
temps, même si on dessine l'armoire comme un polygone.
Si le rendu veut les matérialiser aux zooms les plus forts, il utilisera
man_made=street_cabinet.

Voir les 1ere lignes de
https://wiki.openstreetmap.org/wiki/FR:Tag:man_made%3Dstreet_cabinet


> Peut être que quand les bases des opé seront en OD, on y verra plus clair
> ^^
>

En ce moment c'est précisément pour inciter les opérateurs à ouvrir leurs
données que nous ajoutons tous ces objets
Les comparaisons avec les référentiels internes montrent des différences
sensibles, parfois de plusieurs km, c'est un fait.
Ainsi la contribution peut les aider à corriger tout ça.

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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Bonjour à tous,

La migration a été faite hier soir, pour les nœuds et chemins uniquement
sur un peu plus de 2800 objets.
Il reste 2 relations et 2 occurrences dérivées de ref:ERDF:gdo à traiter
dans les prochaines heures.
Merci de ne plus utiliser ref:ERDF:gdo et de vous reporter exclusivement
sur ref:FR:gdo à partir de maintenant.
N'hésitez pas à compléter les objets visibles autour de chez vous,
compléter ce tag a de la valeur pour lier ces points avec d'autres jeux de
données.

Pas de problèmes à signaler
C'est une bonne expérience à faire pour s'apercevoir des cas d'usage de la
clé et de prendre les meilleures mesures pour mieux guider les
contributeurs.
Cela a aussi été l'occasion de reprendre plusieurs objets, convertir des
nœuds en bâtiments et vice versa.
La qualité globale des données a augmenté normalement, il faut continuer :)

Il va donc s'agir maintenant d'étendre l'utilisation de ref:FR:gdo au
installations de distribution de gaz.
La documentation va finir d'être mise à jour et des tickets créés vers les
éditeurs pour améliorer le contrôle qualité.

Bonne fin d'après-midi

François

Le sam. 7 déc. 2019 à 15:57, François Lacombe  a
écrit :

> Salut à tous,
>
> La motivation de Stéphane sur ref:INSEE m'a motivé pour proposer un autre
> changement sur une clé de référence.
> Il sera pour ma part moins important en volume concerné. Il porterait sur
> le remplacement automatique de ref:ERDF:gdo en ref:FR:Enedis ou ref:FR:gdo
> sur 2700 objets.
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:ERDF:gdo
>
> La justification est de deux ordres :
> - ERDF n'existe plus
> - La référence est propre à la France et ne comporte pas FR. Je trouve que
> ce serait une bonne chose
> => ref:FR:Enedis pourrait convenir
>
> Nous utilisons ref:ERDF:gdo pour documenter les réseaux électriques mais
> le Guide Des Ouvrages est partagé avec les gaziers de GRDF.
> Ainsi ref:FR:gdo permettrait aussi de documenter les affleurant gaziers
>
> N'hésitez pas à donner votre avis sur cette proposition, en tenant compte
> de la volumétrie d'usage :
> https://taginfo.openstreetmap.org/keys/?key=ref%3AERDF%3Agdo
>
> Ce peut aussi être l'occasion de nettoyer un peu les données, parce que
> beaucoup de ces refs sont aussi dans ref=* et pas dans ref:ERDF:gdo
> actuellement.
>
> Bonne après-midi
>
> François
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.25.0

[François Lacombe]

Le dim. 2 févr. 2020 à 18:41, pepilepi...@ovh.fr  a
écrit :

> Le 02/02/2020 à 14:50, Stéphane Péneau a écrit :
>
> Ça m'a tout cassé mes jolies haies  :-(((
>
> https://www.openstreetmap.org/#map=19/47.09460/-1.35571
>
> Natural=scrub est-il incompatible ici ? (si tu veux retrouver tes jolies
> haies...)
>

C'est plutôt pour la broussaille basse, les haies peuvent être composées
d'arbres à part entière.
Et le rendu vert kaki reflète peu la broussaille qu'on trouve ici je trouve

Le dim. 2 févr. 2020 à 19:34,  a écrit :

> Sauf que Stéphane a bien mis area=yes.
>
> https://www.openstreetmap.org/way/458961507
>
> Stéphane, je crois que tu vas pouvoir ouvrir un ticket sur le sujet.
>
Le parti pris est bien de ne plus supporter area=yes sur barrier=hedge
(sans me prononcer si c'est bien ou mal)
https://github.com/gravitystorm/openstreetmap-carto/pull/3844

Bonne soirée

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

[OSM-talk-fr] Proposition - RFC - Organisation des lignes aériennes (consécutive à line_attachment)

[François Lacombe]

Salut à tous,

Nouvelle année, nouvelles propositions. Voici celle que je souhaite pousser
en premier.
Elle est formulée dans le cadre du nettoyage de tower:type et d sa
suppression complète des supports électriques.
Expliqué il y a quelques temps dans mon journal :
https://www.openstreetmap.org/user/InfosReseaux/diary/391058

Elle concerne la topologie et l'organisation des lignes aériennes
(électriques mais pas que).
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Lines_management

La RFC a déjà commencé depuis quelques temps sur la ML internationale, je
viens de finir de traduire en français.
La clé est déjà utilisée à quelques endroits par d'autres utilisateurs.

Il me manque des photos libres de situations comme celle-ci :
https://wiki.openstreetmap.org/wiki/File:Power_line_chart_pole_loop.png
pour compléter les exemples
Si quelqu'un a quelque chose qui ressemble autour de chez lui, je suis
preneur.

Par ailleurs n’hésitez pas à essayer de transcrire ce que vous verriez sur
le terrain avec les valeurs proposées pour s'assurer que tout fonctionne
bien
Auquel cas on pourra compléter les exemples si nécessaire.
Certaines valeurs marchent même pour les remontées mécaniques si vous allez
au ski (tout comme line_attachment=pulley)

Merci par avance pour vos commentaires et bon weekend

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

Re: [OSM-talk-fr] Opportunité de promouvoir OSM : Démonstration T'dat'hack les 31/01 et 01/02

[François Lacombe]

Bonsoir Brice

L'événement est bien maintenu et aura lieu de vendredi midi à samedi midi
Malheureusement les équipes ont été constituées il y a 15 jours et les
accréditations déjà envoyées.

C'est dommage de ne pas avoir pu nous entendre avant la semaine dernière
pour que tu y participes.
Peux-tu te libérer vendredi à partir de 13h ou uniquement le soir ?

François

Le mar. 28 janv. 2020 à 22:14, Brice  a écrit :

> Le 18/12/2019 à 23:11, François Lacombe a écrit :
> > L'Association des Villes et Collectivités Câblées (AVICCA) organise sur
> deux jours, les 31/01 et 01/02, un hackathon un
> > peu particulier à La Paillasse à Paris à destination de ses membres.
> > http://www.avicca.org/actualite/tdathack-territoires-data-et-telecoms
> > http://www.avicca.org/content/tdathack
> (...)
> > Il n'est pas nécessaire d'être familier avec ce domaine de contribution
> pour venir assister les participants. La
> > connaissance et la culture autour d'OSM est ce qui est le plus recherché
> et nous avons ici une belle tribune il me semble.
>
> Bonsoir François,
>
> Cette manifestation est-elle bien maintenue ?
> Je pense pouvoir passer vendredi soir, est-ce le bon moment pour apporter
> un peu de savoir-faire concernant OSM ?
> D'autres contributeurs OSM seront-ils présents ?
>
> Brice Mallet aka Britzz
>
> ___
> 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] Nettoyage Enedis / GRDF

[François Lacombe]

Bonsoir Quentin,

Merci pour les informations, tel qu'expliqué ici ces modifs devraient être
ok.

N'hésitez pas à faire de même chez vous pour se séparer de operator=ERDF
Je m'aperçois que j'en ai encore un peu à faire dans les Alpes

Bonne soirée

François

Le lun. 17 févr. 2020 à 13:17, Quentin Salles 
a écrit :

> Bonjour,
> J'ai effectué la modification des clés ERDF et ENEDIS sur toute la région
> Occitanie. N'étant pas sur de ma contribution, voici ce que j'ai fait :
> - Les postes de transformation basculent vers Enedis après vérification
> sur le site de l'agence ORE
> - Les câbles électriques en surface sont divisés en 2 parties :
> -- Les "minor_line" ont comme opérateur Enedis
> -- Les autres (voltage=63000) ont comme opérateur RTE.
> J'espère ne pas m'être trompé sur mes contributions.
>
> Je n'ai pas réalisé de bascule EDF vers Enedis vu que je ne suis pas assez
> calé pour réaliser ces modifications.
>
> Bonne journée
>
> Quentin
> ___
> 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] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Bonsoir Quentin,

Attention, à ma connaissance sur les réseaux GRDF, seuls les postes de
distribution publics ont un code GDO affichés.
Les valeurs qui commencent par GI ne sont pas des codes GDO

Cela n'empêche pas de les décrire avec
pipeline=substation
substation=delivery
operator=GRDF
ref=GIxx

La documentation est encore très partielle sur le sujet j'en conviens

Bonne soirée

François

Le lun. 17 févr. 2020 à 11:16, Quentin Salles 
a écrit :

> Bonjour François,
>
> Merci pour cet ajout. Je retrouve les cas que j'ai rencontré dans ma
> commune, notamment les postes de distribution privés
>
> ___
> 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] Nettoyage Enedis / GRDF

[François Lacombe]

Bonjour Adrien et merci pour ton action :)

N'hésitez pas à le faire dans votre région également, on sera plusieurs à
être disponibles en cas d'indéterminations

Bon dimanche

François

Le ven. 14 févr. 2020 à 09:21, PanierAvide  a
écrit :

> Bonjour François,
>
> Merci pour ce travail de documentation et d'animation de communauté ! Je
> viens de faire la bascule en Bretagne des operator=ERDF/EDF vers
> operator=Enedis sur le réseau de distribution. Je n'ai pas modifié les
> operator=EDF sur tout ce qui est production d'énergie (centrales
> électriques).
>
> Cordialement,
>
> Adrien P.
>
> Le 14/02/2020 à 00:29, François Lacombe a écrit :
>
> Salut à tous,
>
> Il devenait nécessaire de créer une page wiki pour Enedis et GRDF, nos
> opérateurs de distribution préférés pour documenter les pratiques les
> concernant.
> https://wiki.openstreetmap.org/wiki/FR:Tag:operator%3DGRDF
>
> En particulier Enedis qui mérite un bon nettoyage puisque qu'il y a encore
> ~2500 operator=ERDF et quelques operator=EDF qui traînent (on a dépassé les
> 100 000 pour Enedis)
>
> Un résumé des différentes valeurs est visible ici
> https://wiki.openstreetmap.org/wiki/FR:Tag:operator%3DEnedis
>
> Si certains objets concernés se trouvent dans votre zone de prédilection,
> cela sera utile de mettre la bonne valeur pour operator
> Il est possible de vérifier si Enedis est bien le gestionnaire du réseau
> sur la commune ici
> https://dataviz.agenceore.fr/distributeurs-energie-france/
>
> Au passage, compléter les postes, *poteaux* et autres ouvrages avec
> ref:FR:gdo et name est apprécié
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:gdo
>
> A disposition en cas de questions sur le sujet
>
> Bonne soirée
>
> François
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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

[OSM-talk-fr] Nettoyage Enedis / GRDF

[François Lacombe]

Salut à tous,

Il devenait nécessaire de créer une page wiki pour Enedis et GRDF, nos
opérateurs de distribution préférés pour documenter les pratiques les
concernant.
https://wiki.openstreetmap.org/wiki/FR:Tag:operator%3DGRDF

En particulier Enedis qui mérite un bon nettoyage puisque qu'il y a encore
~2500 operator=ERDF et quelques operator=EDF qui traînent (on a dépassé les
100 000 pour Enedis)

Un résumé des différentes valeurs est visible ici
https://wiki.openstreetmap.org/wiki/FR:Tag:operator%3DEnedis

Si certains objets concernés se trouvent dans votre zone de prédilection,
cela sera utile de mettre la bonne valeur pour operator
Il est possible de vérifier si Enedis est bien le gestionnaire du réseau
sur la commune ici
https://dataviz.agenceore.fr/distributeurs-energie-france/

Au passage, compléter les postes, *poteaux* et autres ouvrages avec
ref:FR:gdo et name est apprécié
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:gdo

A disposition en cas de questions sur le sujet

Bonne soirée

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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Bonsoir à tous

Le mar. 7 janv. 2020 à 16:04, Quentin Salles  a
écrit :

> Bonjour,
>
> Pouvez-vous me confirmer que l'usage de la clé "ref:FR:gdo" est bien actif
> ?
> En faisant une requête Overpass, je n'ai vu qu'une seule utilisation sur
> toute la France.
>
> De plus, je suis novice sur le sujet, mais je pense qu'il serait
> intéressant de parler d'autres cas (notamment le gaz) sur cette page. Qu'en
> pensez-vous ?
>

Suite à la remarque de Quentin ci-dessus, la page est désormais mixte
électricité/gaz, avec des cas d'usages décris pour les deux domaines
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:gdo#Ouvrages_gaziers

Même si la documentation pour le gaz est moins étoffée que pour l'élec, les
postes gaz comme ceux-ci ont bien leur place dans OSM en tant qu'armoires
de rue
https://wiki.openstreetmap.org/wiki/File:French_gas_delivery_point.jpg

Bonne soirée

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

Re: [OSM-talk-fr] ref et ref:FR

[François Lacombe]

En corollaire à ces propositions, je pensais suggérer à l'international de
ne laisser sur la page ref que les références mondiales
J'ai déjà supprimé le peu de ref:FR qui s'y trouvaient, en laissant
évidemment les liens vers la page française des références nationales.

Cela permettra de clarifier les choses entre mondial/national et d'inciter
les pays à créer leurs propres page et namespace

Penser qu'il y a aussi un niveau continental, avec quelques entrées en
Europe par exemple
https://wiki.openstreetmap.org/wiki/FR:Key:ref:EU:EVSE
https://wiki.openstreetmap.org/wiki/Key:ref:EU:ENTSOE_EIC

Bonne soirée

François

Le mar. 11 févr. 2020 à 23:47, François Lacombe 
a écrit :

> Bonsoir à vous
>
> +1 avec vous, bonne idée de séparer le tableau, pourquoi pas par thèmes,
> comme nous le faisons pour les Map Features ?
> Sur le caractère national/local, pourquoi pas ajouter une colonne dans les
> tables pour le préciser ?
>
> Globalement, tout ce qui favorise l'adoption de ref:FR:* est bon à prendre.
>
> François
>
> Le mar. 11 févr. 2020 à 18:57, deuzeffe  a
> écrit :
>
>> Hello,
>>
>> Le 11/02/2020 à 18:25, leni a écrit :
>> > Bonjour
>> >
>> > En attendant que nous trouvions une meilleure solution pour certaines
>> > ref:FR:*** , je pense qu'il serait bien de partager le tableau de la
>> > page
>> >
>> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
>> > (1) en deux parties :
>> > - une première partie avec les références qui s'appliquent sur
>> > l'ensemble du territoire (ref:FR:ARCEP=* ; ...) en y ajoutant celles
>> que
>> > j'ai trouvées dans le wiki (2)
>> > - une partie pour les autres (ref:FR:CRTA=*en Aquitaine ;
>> > ref:FR:BSPP:=* ; ref:FR:RATP=*) en y ajoutant celles que j'ai
>> > trouvées dans le wiki (3)
>> > - Faut-il y ajouter ref:FR:TransGironde et ref:FR:CUB qui sont dans osm
>> > et que je n'ai pas trouvées dans le wiki ?
>> >
>> > Qu'en pensez-vous ?
>>
>> Sur le partage, que du bien. Et peut-être "l'ordonner" voire le découper
>> par thème ?
>> Il me semble que j'en avais déjà parlé, sans grand succès...
>>
>> --
>> deuzeffe - qui n'a pas oublié la page transport à toiletter.
>>
>> ___
>> 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] ref et ref:FR

[François Lacombe]

Bonsoir à vous

+1 avec vous, bonne idée de séparer le tableau, pourquoi pas par thèmes,
comme nous le faisons pour les Map Features ?
Sur le caractère national/local, pourquoi pas ajouter une colonne dans les
tables pour le préciser ?

Globalement, tout ce qui favorise l'adoption de ref:FR:* est bon à prendre.

François

Le mar. 11 févr. 2020 à 18:57, deuzeffe  a écrit :

> Hello,
>
> Le 11/02/2020 à 18:25, leni a écrit :
> > Bonjour
> >
> > En attendant que nous trouvions une meilleure solution pour certaines
> > ref:FR:*** , je pense qu'il serait bien de partager le tableau de la
> > page
> >
> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
> > (1) en deux parties :
> > - une première partie avec les références qui s'appliquent sur
> > l'ensemble du territoire (ref:FR:ARCEP=* ; ...) en y ajoutant celles que
> > j'ai trouvées dans le wiki (2)
> > - une partie pour les autres (ref:FR:CRTA=*en Aquitaine ;
> > ref:FR:BSPP:=* ; ref:FR:RATP=*) en y ajoutant celles que j'ai
> > trouvées dans le wiki (3)
> > - Faut-il y ajouter ref:FR:TransGironde et ref:FR:CUB qui sont dans osm
> > et que je n'ai pas trouvées dans le wiki ?
> >
> > Qu'en pensez-vous ?
>
> Sur le partage, que du bien. Et peut-être "l'ordonner" voire le découper
> par thème ?
> Il me semble que j'en avais déjà parlé, sans grand succès...
>
> --
> deuzeffe - qui n'a pas oublié la page transport à toiletter.
>
> ___
> 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] Intégration supports radio ANFR : différences mast/tower

[François Lacombe]

Salut à tous,

Des questions relative à l'intégration Osmose des supports ANFR
Sur le support suivant, initialement qualifié en pylône :
https://www.openstreetmap.org/node/4026894947, on a man_made=mast

Cartoradio dit "Pylône autostable", et StreetView laisse penser que c'est
bien un pylône
https://www.google.fr/maps/@45.9114338,0.857628,3a,30.6y,1.47h,99.93t/data=!3m6!1e1!3m4!1sHfbTlTDRbyfCi-iCaOKDIw!2e0!7i13312!8i6656

Pourquoi le choix d'utiliser mast ici?
Je n'ai pas beaucoup participé aux discussions et j'ai pu passer à côté de
quelque chose.

Autre cas : https://www.openstreetmap.org/node/6925034943
Celui-ci est en fait sur le pylône électrique tout proche (street view pas
à jour mais il n'y a pas de doute vu la distance) :
https://www.openstreetmap.org/node/1645500132

Cartoradio dit "Pylône autostable", ce qui n'est pas faux, mais je devrais
leur suggérer de créer la catégorie pylône électrique sans quoi la simple
indication RTE ne permet pas de distinguer les pylones telecom des pylones
électriques (et il faudra bien conserver power=tower sans man_made=tower)

Bref, preneur des avis des uns et des autres, merci par avance

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

Re: [OSM-talk-fr] Limite numérique des identifiants de noeuds/ways OSRM

[François Lacombe]

Bonjour

Une issue a été ouverte relativement à ce problème, avec un extrait sur la
commune de Saint-Christo en Jarez.
https://github.com/Project-OSRM/osrm-backend/issues/5644

Par ailleurs et malgré les id de longueur importante, le routage se fait
correctement et les routes sont bien renvoyées.

N'hésitez pas à commenter ou constater ce que je remonte, pour être sur que
je ne fasse pas d'erreur

François

Le mer. 8 janv. 2020 à 22:58, François Lacombe 
a écrit :

>
> Le mer. 8 janv. 2020 à 22:04, Julien Coupey  a écrit :
>
>> Il y a quand même pas mal de gens qui
>> continuent à utiliser OSRM et tout ce petit monde a intérêt à ce que ça
>> fonctionne. ;-)
>>
>
> Je n'en doute pas vu le nombre de forks sur le dépôt du backend c'est
> impressionnant.
>
> A la base, j'en suis arrivé à cette solution (utiliser annotations=nodes)
> parce qu'il y avait ce soucis-là sur lequel personne n'a jamais réagit
> https://github.com/Project-OSRM/osrm-backend/issues/5190
>
> Il n'y a pas de jeu de données d'entrée en effet, il faudra que je vois si
> je ne peux pas sortir un extract dans ce coin également.
> Mais il faut aussi fournir les profils utilisés pour produire la réduction
> et je n'y suis pas autorisé
>
> Bonne soirée
>
> François
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Intégration supports radio ANFR : différences mast/tower

[François Lacombe]

Merci Jérôme pour les précisions

Je pense qu'il faudrait faire le changement si c'est possible pour ceux qui
connaissent le script

François

Le ven. 10 janv. 2020 à 02:08, Jérôme Amagat  a
écrit :

>
>
> Le jeu. 9 janv. 2020 à 22:05, François Lacombe 
> a écrit :
>
>> Bonjour et merci pour votre retour,
>>
>> On sera d'accord sur le "escalade dehors ou dedans"
>> Mais pour les pylônes auto-stables, l'échelle est à l'intérieur du
>> treillis le plus souvent donc c'est plutôt man_made=tower qu'il faudrait
>> utiliser
>>
>> A la différence d'un poteau où il faut y accéder en nacelle
>> obligatoirement (man_made=mast)
>>
>> Je pense que ce qui m'a fait faire ce choix c'est sur le wiki
> man_made=mast : https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmast
> "Unlike a man_made=tower which is accessible and provides platforms, a
> man_made=mast only offers ladder steps to climb it on the outside."
>
> et man_made=tower :
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dtower
> "A tower is accessible and provides platforms, whereas a mast only offers
> ladder steps to climb it."
> et le "often" dans "In comparison a man_made=mast is often a single mast
> of concrete or steel."
>
> Mais je suis pas contre un changement, j'ai pas d'avis...
> ___
> 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] [dérivé de "OSMOSE et Opendata"] Comment tagguer ces transformateurs ?

[François Lacombe]

Bonsoir et merci d'avoir apporté quelques réponses

J'ajoute ce lien également
https://wiki.openstreetmap.org/wiki/Power_networks/France#Postes_de_transformation_locaux
La page du projet du mois de juillet 2018 est maintenue dans son état
d'origine sans mise à jour.

Au passage, je précise que ce que vous appelez des "transformateurs" dans
le langage courant sont des postes. Les transformateurs sont des machines à
l'intérieur des postes et on peut en trouver plusieurs à l'intérieur d'un
même poste.
C'est pourquoi nous utilisons power=substation sur les sites et
power=transformer bien souvent comme des nœuds sur les machines.
C'est aussi pourquoi power=transformer est incompatible avec building=*.

Happy mapping

François


Le dim. 12 janv. 2020 à 19:01, deuzeffe  a écrit :

> Voire
>
> https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/postes_electriques
> tout court
>
> Le 12/01/2020 à 18:58, deuzeffe a écrit :
> > Le 12/01/2020 à 18:54, pepilepi...@ovh.fr a écrit :
> >
> >> Cré vindioux, y'a du boulot !
> >>
> >> Mais comment faut-il les tagguer, ces machins ?
> >
> > Voir ici :
> >
> https://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/postes_electriques#Statistiques_et_participation
> > ?
> >
> > Happy mapping !
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Les Data Items : discussion en cours

[François Lacombe]

Salut à tous,

Nous avions survolé le sujet au précédent SOTM, notamment lors de la
présentation de JOSM par Vincent
(
https://peertube.openstreetmap.fr/videos/watch/adbeec6c-a3cc-406b-8f0b-4c50990dedc3
à 49:20)

Une discussion supplémentaire a été lancée sur le wiki pour proposer la
généralisation des "DataItems" pour décrire les tags (en anglais)
https://wiki.openstreetmap.org/wiki/Talk:Wiki#Transition_to_use_data_items_when_this_can_be_done_without_loosing_information

Ca va demander encore beaucoup de temps de se pencher sur la question et de
répondre à toutes les critiques.
Comme je l'ai écris à l'instant à la suite des autres contributions, je
suis sur surpris de la levée de bouclier que cela suscite.
Un énorme travail a déjà été fait par plusieurs membre pour l'intégrer et
proposer déjà des premières connexions. Mais à court terme et à juste titre
il reste des point d'expérience utilisateur à régler avant que le système
soit pleinement utilisable. D'autres arguments sont levés et je ne
comprends pas : le wiki code sur 126 traductions toutes non à jour pour la
même clé c'est mieux qu'un item centralisé à l'image de wikidata. Il faut
savoir garder son calme.

On ne va pas refaire le match ici, contribuez directement sur le wiki si
vous maîtrisez l'anglais et que vous voulez ajouter quelque chose (sinon il
n'y a rien d'autre à faire qu'attendre)
Pour avoir relevé dans une bien moindre mesure ce genre de défis
précédemment, je me dit que finalement le problème n'est pas technique, il
est avant tout humain.

Comme d'habitude on soulignera les contributions positives sur le trac de
JOSM où des solutions sont recherchées pour produire les presets et
maintenir à jour les traductions. Merci à eux
https://josm.openstreetmap.de/ticket/17842

Soyez sûr qu'on sera plusieurs à parler du sujet au prochain SOTM-fr

Bonne soirée

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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Il n'y a pas eu de nouvel échanges dans ce fil

Il me semble donc que je peux procéder à la migration ?
En tout cas passer de ref:ERDF:gdo à ref n'est pas possible sans perdre
l'information sur ce qui est effectivement présent sur le terrain (ref=P 57
vs ref:ERDF:gdo=19132P0057)
Sauf erreur je crois qu'une réponse a été apportée sur tous les points
levés.

Si vous avez une nouvelle objection levez la main assez vite s'il vous plaît

Bonne soirée

François

Le mer. 8 janv. 2020 à 13:33, François Lacombe 
a écrit :

> Bonjour Marc,
>
> Je suis d'accord avec Yves ici
> Ce n'est pas parce qu'un objet ne porte qu'une référence, qu'on ne peut
> pas associer des règles de validation ou de formatage particulières sur
> celle-ci.
> Plus que les tags de l'objet et le contexte d'utilisation de ref=*, il
> faut une clé dédiée à laquelle on associe une doc complète et des règles
> dans les éditeurs.
>
> Même si certaines fois l'exploitant est repris dans le nom de la ref
> (ref:FR:Orange par exemple), ce n'est pas le but de déterminer l'exploitant
> avec la ref;
> Nous n'avons pas le droit de reprendre systématiquement le nom du
> référentiel à cause de la propriété intellectuelle, donc on utilise la
> marque à la place qui correspond au nom de l'exploitant.
>
> Je serai bien embêté si il fallait exprimer sur la même page les règles
> pour ref:FR:gdo et ref:FR:FINESS. Ce n'est pas du tout la même chose, ce
> serait éminemment plus complexe à valider aussi.
>
> Voir aussi les objets qui portent plusieurs ref : ref:FR:ARCEP +
> ref:FR:Orange (avoir ref + ref:FR:Orange n'a pas plus de sens que
> ref:FR:ARCEP + ref)
>
> On utilise enfin les namespaces parce que ces règles, concepts et
> référentiels sont spécifiques à la France et peuvent collisionner ailleurs
> dans le monde.
>
> Le mar. 7 janv. 2020 à 16:20, marc marc  a
> écrit :
>
>> Bonjour,
>>
>> Le 07.01.20 à 16:01, Quentin Salles a écrit :
>> > Pouvez-vous me confirmer que l'usage de la clé "ref:FR:gdo" est bien
>> actif ?
>>
>> Nous n'avions pas terminé la discussion sur la migration.
>> Je te conseille d'utiliser l'ancienne clef en attendant, puisque
>> c'est elle qui est la façon de faire actuellement.
>>
>
> Je n'ai pas fait la migration, pour l'ancienne clé reste valable.
> Y a-t-il d'autres points à discuter ?
>
>
>> je vais faire une comparaison avec les routes :
>> en lisant une référence sur le panneau d'une route, cette référence
>> se retranscrit dans la clef ref=numéro et ceci indépendamment de
>> l'opérateur ou du pays.
>>
>
> Parce qu'on traduit avant tout ce qu'on lit sur le terrain sans chercher à
> la rapprocher d'un référentiel quelconque.
>
>
>> on n'utilise pas non plus d'espace de nom du genre ref:FR:auteur
>> pour préciser qui serrait l'auteur de la ref.
>> on n'utilise pas non plus de mot dans la clef pour donner le sens de
>> cette référence ou le terme légal que celui-ci aurait dans la loi.
>>
>
> Et on pourrait, mais le domaine routier n'est pas le meilleur pour
> produire des référentiel, je ne connais pas le nom de la base de données
> qui attribue les numéros de routes.
>
>
>> A l'inverse, dans le domaine énergétique (et des transports), au fil
>> du temps, on utilise des espaces de nom pour la clef ref en France,
>> sans que je perçoive ni le besoin ni même l'intérêt.
>>
>> Au final l'utilisateur qui lit une ref quelque part, ne peux pas
>> l'ajouter dans osm sans devoir chercher dans le wiki quel est la règle
>> particulière qui régit cet objet dans ce pays.
>>
>
> C'est nécessaire parce qu'on a besoin de formater cette valeur par rapport
> à ce qui est lu sur le terrain : infos incohérentes, valeurs partiellement
> effacées, techniciens fatigués...
>
>
>> cela nuit à mon avis grandement à l'encodage simple et même à
>> l'utilisation (essayez donc de connaître le nombre de power=substation
>> au niveau mondial qui ont une ref, vous devez écrire une règle qui dit
>> que cela peux être ref ou ref:* chose que de nombreux outil tel que
>> tainfo ou overpass ne permettent pas ou pas facilement)
>>
>> > Est-il possible de remonter l'information
>> > via l'Open data. Si oui, est-il permis d'ajouter ces informations non
>> > visibles sur le terrain ?
>>
>> bien sur, osmose ne propose rien sur le sujet ?
>> https://osmose.openstreetmap.fr/fr/map/
>
>
> Pas encore mais la migration va être l'occasion d'ajouter de la validation
> dans JOSM et Osmose quand j'aurais le temps de m'en occuper.
> * substation=minor_distribution + operator=Enedis + ref=* => Alerte, il
> manque ref:FR:gdo
> * operator!=Enedis;GRDF + ref:FR:gdo => Alerte, ce n'est pas possible
>
> Et ainsi de suite
>
> François
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Manque d'attribution, supprimer les cas résolus - wiki

[François Lacombe]

Salut à tous

D'accord avec Marc, je souhaite aussi avoir une liste des cas qu'on a
traité.
Non pas pour les réciter toutes les semaines mais aussi pour bien avoir à
l'esprit que c'est un travail permanent.

Le problème des évolutions de ces sites et le suivi des échanges passés
(l'attitude adoptée par l'équipe à ce moment là, etc...) est important.

Ok pour réorganiser la page, moins pour supprimer les cas rencontrés donc

Bonne soirée
François

Le mer. 15 janv. 2020 à 18:54, Cyrille37 OSM 
a écrit :

> Merci Marc, j'entends ton argument.
>
> Cyrille.
>
> ps: you win ! :D
>
> Le 15/01/2020 à 18:22, marc marc a écrit :
> > Hello,
> >
> > Le but est de pouvoir répondre différemment à celui qui commet
> > une erreur <> l'entreprise bricole la prod sous la pression
> > mais perd l'info à chaque maj parce que pas remonté comme il faut.
> >
> > ceci dit je suis tout a fait d'accord pour un droit à l'oubli.
> > mais pas avec un délai "instantané".
> > Il y des infos à ce sujet dans une loi ou une jurisprudence ?
> > Sinon au pif 1 an me semble bien, si c'est déplacé sur une page annexe.
> >
> > Pour l'histoire de "c'est pas les mêmes gars", je ne suis pas d'accord.
> > on ne vise pas l'humain qui était affecté à la tâche,
> > on vise le site. la fréquence de changement des gars qui s'en occupent,
> > cela peux se comprendre comme "raison" mais cela ne nous regardent pas
> > et cela ne doit sûrement pas être accepté comme excuse pour justifier
> > un problème récurent, si cela se produit.
> >
> > Cordialement,
> > Marc
> >
> > Le 15.01.20 à 18:11, Cyrille37 OSM a écrit :
> >> Hello
> >>
> >> Marc, à quoi servirait d'avoir l'histoire ? Une fois le site mit en
> >> conformité, l'affaire est terminée. Si un jour le même site pose à
> >> nouveau problème c'est une autre "histoire", non ?
> >>
> >> À mon avis un site qui se retrouve à nouveau en défaut d'attribution un
> >> an après, n'est pas le même site: c'est une nouvelle version, une
> >> nouvelle équipe, ou un nouveau je ne sais quoi.
> >>
> >> Je fais un peu le parallèle avec le "droit à l'oubli", qui existe même
> >> en justice, qui selon la gravité oublie les fautes, de façon que si tu
> >> refais une faute après un certain délai on ne te reprochera pas les
> >> fautes précédentes puisqu'elles sont oubliées.
> >>
> >> Dit encore autrement, je n'aime pas conserver des infos qui me
> >> permettrai d'accumuler des reproches pour le prochain désaccord. ;-)
> >>
> >> Cyrille.
> >>
> >> Le 14/01/2020 à 13:26, marc marc a écrit :
> >>> Le 14.01.20 à 12:14, Cyrille37 OSM a écrit :
>  il me semble qu'il serait plus "poli / respectueux"
>  de supprimer les cas résolus
> >>> Il ne faut en effet pas les garder comme "à problème"
> >>>
> >>> Mais les effacer pose le soucis de l'historique, càd le manque
> >>> de possibilité de recherche :
> >>> regarde le dernier site ajouté, c'est "ajout site".
> >>> si celui-ci est supprimé avec comme résumé "suppression site",
> >>> tu n'as aucun moyen de retrouver son existence hormis regardant chaque
> >>> modif.
> >>>
> >>> Je verrais bien une page d'archive, un peu comme cela se fait avec les
> >>> pages de proposition. le contenu passé est caché derrière un clic.
> >>> je me demande même si cela ne disparait pas aussi du moteur de
> recherche
> >>> (à vérifier). mais cela permet au moins de se rendre sur la page
> >>> d'archive, avoir la date de l'incident, la date de résolution. bref
> >>> savoir si besoin au lieu de réécrire l'histoire.
> >>> ___
> >>> 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
>
> ___
> 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] Il est partout, quelle énergie (à faire parfois quand même !)

[François Lacombe]

Bonjour et merci Vincent,

On a eu un bon échange avec la journaliste. Et le propos dans l'émission a
plutôt bien traduit tout ca donc c'est super.

Je sais que le profit n'est pas ce qui nous anime ici, et que la
rétribution prend bien d'autres formes que la rentabilité financière.
Par contre c'est un indicateur intéressant que de savoir quelle quantité
d'énergie des institutions est économisée par les contributions sur OSM.
Le chiffre donné par Gabriel Attal sur les bénévoles des restos du cœur
donne déjà une idée (bien que sûrement imparfait)

On verra si à l'avenir des progrès sont fait pour l'évaluer.

François

Le ven. 17 janv. 2020 à 16:17, Jacques Lavignotte 
a écrit :

>
>
> Le 17/01/2020 à 15:27, Vincent Bergeot a écrit :
>
> > François Lacombe a réussi à placer OpenStreetMap :)
>
> Oui ! En live ce matin.
>
> Bravo !
>
> Vraie question que la valorisation du bénévolat...
>
> J.
>
> --
> GnuPg : 156520BBC8F5B1E3 Because privacy matters.
> On mangera ? (c) (tm)
>
> ___
> 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] Intégration supports radio ANFR : différences mast/tower

[François Lacombe]

Bonjour et merci pour votre retour,

On sera d'accord sur le "escalade dehors ou dedans"
Mais pour les pylônes auto-stables, l'échelle est à l'intérieur du treillis
le plus souvent donc c'est plutôt man_made=tower qu'il faudrait utiliser

A la différence d'un poteau où il faut y accéder en nacelle obligatoirement
(man_made=mast)

Bonne soirée

François

Le jeu. 9 janv. 2020 à 02:55, Jérôme Amagat  a
écrit :

> C'est moi qui est fait ces choix pour osmose.
> J'ai fait ce choix personne n'en a parler sur la discussion sur le github
> d'osmose donc c'est resté comme ça.
> La lecture des pages du wiki pour man_made=mast et man_made=tower m'a fait
> faire ce choix.
> Ce que j'ai compris c'est comme dit marc marc : tower si il y a un
> intérieur ou au moins des plateformes et mast sinon donc pour les pylônes
> j'ai mis mast. man_made=tower serait plutôt pour ce que l'on appelle en
> français des "tours" donc pas trop les pylônes.
> Le problème c'est que ce n'est pas en accord avec power=tower. Et peut
> être pas trop avec les définitions de tower et mast ...
>
> le code est là :
> https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merge_radio_support_FR.py
>
>
>
>
> Le jeu. 9 janv. 2020 à 01:46, marc marc  a
> écrit :
>
>> Le 09.01.20 à 01:39, François Lacombe a écrit :
>> > Je n'ai pas beaucoup participé aux discussions
>>
>> de mémoire, sur tagging, la différence avait surtout été mis
>> sur comment on y monte : mat par dehors, polygone par dedans.
>> ___
>> 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

Re: [OSM-talk-fr] Limite numérique des identifiants de noeuds/ways OSRM

[François Lacombe]

Merci Julien, je vais essayer de fournir un fichier de ce style là pour une
issue
Effectivement je pense que c'est un bug aussi

Sais-tu si l'équipe les traite encore?
Les derniers essais que j'ai fait n'ont pas obtenus de réponse.

Bonne soirée :)

François

Le mer. 8 janv. 2020 à 16:06, Julien Coupey  a écrit :

> Re
>
> Si tu récupères en sortie (dans l'objet `annotation.nodes` d'une route)
> des ids de nœuds qui ne sont pas dans les données d'entrée, alors c'est
> un bug, même si ça n'a apparemment pas de lien avec le fait que les
> valeurs soient supérieures à 2^32.
>
> Ça vaudrait certainement le coup d'ouvrir un ticket avec un exemple
> minimal pour reproduire. C'est peut-être ça le plus compliqué dans ton
> cas car tu sembles utiliser des nœuds renumérotés à la main. Peut-être
> réduire l'extrait OSM à un simple way composé de nœuds problématiques
> pour pouvoir le fournir ?
>
> À +
> Julien
>
> On 08/01/2020 12:29, François Lacombe wrote:
> > Bonjour Julien,
> >
> > Merci pour ta réponse, ça me rassure tout de même.
> > Pour les identifiants de ways, c'est moins problématique pour moi.
> >
> > Ce qui ne passe pas, c'est que j'injecte un XML qui comporte des noeuds
> > identifiés avec
> > 91220288029161
> > 91220288025445
> > 91220288026438
> >
> > Et qui ressortent avec des identifiants tronqués à 10 digits (ce ne sont
> > pas les mêmes noeuds). En tout cas ces identifiants là ne sont pas
> > présents dans le .osm d'entrée.
> > 1885473760
> > 246430160
> > 5846804688
> > 737485280
> > 8063904192
> >
> > 8063904192 étant déjà supérieur à la limite 32 bits, j'ai pensé à une
> > limitation à 10 digits
> >
> > Une idée du problème ?
> >
> > François
> >
> > Le mer. 8 janv. 2020 à 11:41, Julien Coupey  > <mailto:o...@coupey.fr>> a écrit :
> >
> > Bonjour François
> >
> > OSRM supporte normalement sans problème les ids OSM sur 64 bits pour
> > les
> > nœuds depuis un moment[1]. Ce n'est pas le cas pour les ways (ids
> > toujours sur 32 bits) mais a priori il y a de la marge si tu utilises
> > les données OSM telles quelles.
> >
> >   > ca ne passe pas.
> >
> > Si tu peux développer un peu sur ce qui coince, peut-être que ça
> > vaut le
> > coup d'ouvrir un ticket ?
> >
> > [1] https://github.com/Project-OSRM/osrm-backend/pull/1793
> >
> > À +
> > Julien
> >
> > On 08/01/2020 11:19, François Lacombe wrote:
> >  > Bonjour la liste
> >  >
> >  > Est-ce que quelqu'un familier avec OSRM saurait me dire quelle
> > est la
> >  > limite exacte pour les identifiants de nœuds et de chemins OSM?
> >  >
> >  > Je remarque que ces identifiants ne dépassent pas 10 digits dans
> les
> >  > réponses fournies par l'API route.
> >  > On en est à 5700014039 de nœuds dans la base, le plafond va
> > bientôt être
> >  > atteint.
> >  > La maintenance de ces derniers mois est au ralenti, fort à parier
> > que ce
> >  > ne sera bientôt plus utilisable?
> >  >
> >  > Perso je régénère des fichiers xml osm avec des identifiants 64
> > bits et
> >  > ca ne passe pas.
> >  >
> >  > Preneur de vos commentaires, merci par avance
> >  >
> >  > François
> >  >
> >  > ___
> >  > Talk-fr mailing list
> >  > Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
> >  > https://lists.openstreetmap.org/listinfo/talk-fr
> >  >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org <mailto: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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Limite numérique des identifiants de noeuds/ways OSRM

[François Lacombe]

Le mer. 8 janv. 2020 à 22:04, Julien Coupey  a écrit :

> Il y a quand même pas mal de gens qui
> continuent à utiliser OSRM et tout ce petit monde a intérêt à ce que ça
> fonctionne. ;-)
>

Je n'en doute pas vu le nombre de forks sur le dépôt du backend c'est
impressionnant.

A la base, j'en suis arrivé à cette solution (utiliser annotations=nodes)
parce qu'il y avait ce soucis-là sur lequel personne n'a jamais réagit
https://github.com/Project-OSRM/osrm-backend/issues/5190

Il n'y a pas de jeu de données d'entrée en effet, il faudra que je vois si
je ne peux pas sortir un extract dans ce coin également.
Mais il faut aussi fournir les profils utilisés pour produire la réduction
et je n'y suis pas autorisé

Bonne soirée

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

Re: [OSM-talk-fr] 1ere mondiale (enfin je crois) : le réseau de transport électrique français est routable

[François Lacombe]

Bonsoir et merci pour vos encouragements
Je pense faire un diary pour donner quelques explications en plus

Le mar. 7 janv. 2020 à 08:42, Christian Quest  a
écrit :

>
> Je me posais justement la question de savoir si l'on pouvait une
> interface du genre "par où arrive mon électricité ?"
>

Ce serait très intéressant ça
Il y a même des solutions qui existent pour déterminer la part d'éolien, de
nucléaire, de solaire à instant T en plusieurs points du réseau (sinon tous)
C'est le but du projet Kelelekici chez RTE.


> Je me suis posé la question avec l'ouverte de données Enedis, qui
> désormais me permettent de savoir à quel transformateur HT/BT je suis
> raccordé, et de savoir à quel poste électrique il est lui même raccordé
> et bien sûr par où passent les câbles... mais au delà, ça se complique
> c'est sûrement plus maillé et moins capillaire.
>

Il y a un problème de connectivité : les câbles ne sont pas connectés au
poste. Il y a un traitement à faire pour les rapprocher en fonction de
certaines règles
Ca peut se faire avec postgis toutefois

Pour relier le poste de quartier avec la source, il faut connaître l'état
des interrupteurs. Parce que si le poste est sur une boucle alimentée, elle
se referme obligatoirement sur la même source.
La carto ne suffit pas bien qu'essentiel pour le déterminer

On y parviendra dans quelques années je pense


> La mauvaise nouvelle (relative) pour mon datacenter de la cave, c'est
> que je ne suis pas sur le transfo de la clinique de mon quartier, ni sur
> celui de la mairie.
>

Avec les grèves et actions en tout genre, cela vaut mieux ;)

Bonne soirée

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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Bonsoir Quentin,

Le mer. 8 janv. 2020 à 14:38, Quentin Salles  a
écrit :

> Bonjour,
>
> Pour l'instant, je vais rester sur le tag actuel, à savoir "ref:FR:ERDF".
> Et je complèterai par "ref" pour l'information que je vois sur le terrain.
>
C'est la bonne démarche


> Osmose signalé bien les élements manquants, mais aucun identifiant ou même
> nom n'est indiqué. Serait-il possible d'avoir l'identifiant en OpenData ?
>
Cela a été demandé à plusieurs reprises
Si tu as le courage de tout lire, l'opendata des réseaux elec n'est pas si
tranquille :
https://teamopendata.org/t/les-gestionnaires-de-distribution-electrique/1018


> Concernant le gaz, me donner vous l'autorisation de compléter la page Wiki
> OSM "ref:FR:gdo" ?
>
Ce serait même très bien accueilli
Si cela est possible, est-ce envisageable de respecter la même trame pour
les possibilités gaz sur cette page s'il te plaît?

Bonne soirée

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

Re: [OSM-talk-fr] 1ere mondiale (enfin je crois) : le réseau de transport électrique français est routable

[François Lacombe]

Le mer. 8 janv. 2020 à 23:58, marc marc  a
écrit :

> l'étendue de distribution d'un transfo est-elle connue ?
> ou pour le dire autrement, peux-t-on avoir l'info inverse :
> tel transfo alimente tel rue + tel rue + tel rue ?
>

On peut la retrouver via le réseau en regardant les câbles basse tension
qui sortent du poste pour aller vers des adresses.
Attention, parfois plusieurs câbles provenant de postes différents peuvent
passer devant une même adresse.

Il me semble que dernièrement Engie était en procès avec Enedis puisque ce
dernier ne voulait pas communiquer les polygones des zones arrières de
postes pour l'organisation de ses communautés d'autoconsommation.
Il vaut mieux avoir les polygones pour réduire le risque d'erreurs, voire
des points adresse directement qualifiés par l'exploitant (comme sur
http://cartefibre.arcep.fr pour la fibre) puisque la BAN est maintenant
ouverte :)
Et encore à une adresse tu serais capable de trouver des points de
livraison alimentés par deux transfos du même poste ou deux postes
différents (penser aux gros immeubles)

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