from:"François Lacombe"

Le 6 juillet 2016 à 12:47, JB  a écrit :

> Apparemment pas tant que ça :
> http://www.openstreetmap.org/user/SomeoneElse/diary/38988
> Par contre, gérer la double entrée sur les ways et relation, peut-être
> plus.
>

Parce qu'il ici, on passe par osm2pgql et c'est lui qui supporte la
conversion relation => chemin avec les bons attributs.
mapnik n'était peut-etre pas le bon exemple.

Ce que je voulais dire était que mapcss à lui tout seul n'était pas capable
de préciser une récupération de l'attribut depuis la relation dont le
chemin est membre.
Sur JOSM par exemple, bien que je ne sache pas comment c'est traité en
interne, ca ne marche pas.

Quoi qu'il en soit, la redondance sur ref=* n'est donc pas nécessaire,
merci pour l'info.



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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

Le 6 juillet 2016 à 20:03, Jérôme Amagat  a écrit :
>
>
> Ce que je voulais dire par cette ajout c’était pour différencié route dans
> le sens de la chaussée comme tu le dis et route, un itinéraire. Si tu te
> place n'importe où de la chaussée de la D31, tu peux dire que tu es sur la
> D31. par contre quelqu'un a pied sur l'itineraire du bus de la ligne L6 il
> ne dira jamais qu'il es sur la la L6.
>
Ça serait valable si en "ville" "les gens" savaient encore où passent les
départementales. Et vu qu'en "ville", "les gens" utilisent les noms de rue,
on ne doit pas mettre D xx mais le nom de la rue ?

Il pourrait aussi dire qu'il est sur l'itinéraire bis numéro 2, sur
l'itinéraire spécial 34 ou bien sur la route des convois exceptionnels.
Comment ça vous ne le dites pas vous ?

Enfin, chacun appelle sa route comme il le souhaite, c'est aussi un
avantage des relations : on se partage tous le même chemin, mais on ne
l’appelle pas de la même façon.
Où il est écrit que le bout de route doit comporter la référence de
l'itinéraire le plus connu qui passe dessus ? (et encore, le plus connu ça
reste à démontrer).



>
> D31 c'est pas un itinéraire c'est une route c'est du concret.
>
Pas pour tous en tout cas, certains centres d'exploitation n'utilisent pas
les numéros de départementale mais des numéros de section de chaussée.


> Une maison non plus n'est pas un objet physique, le mur en parpaing oui la
> charpente, la porte et c'est parce qu’on le décide que cette ensemble est
> une maison.
>

Tu vas te heurter au problème de l'échelle, est-ce réalisable de dessiner
la charpente sous josm ?
Dessiner plein de bout de route, y compris les obstacles, ronds point et
autre oui.


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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

Bonjour Alain,

Le 6 juillet 2016 à 16:31, Alain VASSAULT <
alain.vassa...@tranquillement.info> a écrit :

> Désolé si je.dis une bêtise car je débute mais sur le wiki ils recommande
> réf pour le Ax et réf_Nat pour le Exxx il me semble.
>

C'est ce qu'on trouve ici en effet
http://wiki.openstreetmap.org/wiki/Key:ref#Examples_on_ways
On fait donc porter à tous les tronçons plusieurs ref différentes.

Le 6 juillet 2016 à 17:07, Jérôme Amagat  a écrit :

> Pas d'accord : Pour ta D31 c'est la ref de la route (c'est bien ce que
l'on tag dans osm avec highway) meme si il y a des chose annexe alors que
pour ta L6 c'est la ref d'un trajet avec des arrêts voir des horaires.
Pas d'accord non plus, c'est pas parce qu'on le tag dans OSM que ca
correspond à la réalité :)
Ce peut être commode, et encore ici je ne trouve pas parce que les
modifications sont très mal gérées avec ce modèle.

D31 et L6 sont deux itinéraires qui empruntent des tronçons de route, les
horaires sont attachés aux véhicules qui y circulent.

Le 6 juillet 2016 à 17:31, Pierre-Yves Berrard <
pierre.yves.berr...@gmail.com> a écrit
> Car aucun way ne porte le tag ref=L6.
> Donc une requête comme celle montrée par Christian ((
http://overpass-turbo.eu/s/hal) ne marchera pas.
Là on est d'accord, et je suis également pour qu'aucun way ne porte ref=D 31

> Note bien que je ne suis pas fondamentalement contre créer des relations
pour une RD. Je voulais juste confirmer le fait que s'il s'agit juste une
collection de highway, overpass ferait bien le job.
Oui ça on est d'accord

Le 6 juillet 2016 à 18:02, Stéphane Péneau  a
écrit :
> Une route départementale est un objet physique.
> Une ligne de transport ne l'est pas.
Dans un cas comme dans l'autre, la chaussée est l'objet physique.

La route départementale est une succession de tronçons de chaussée, la
ligne de transport est une succession de tronçons de chaussée ou de chemin
de fer
Et sur les mêmes tronçons de chaussée qu'empruntés par une route
départementale on trouve également les itinéraires bis, les itinéraires
pour les convois exceptionnels, etc

Parce que si la ligne de transport passe en site propre, on ne dit pas pour
autant que la ligne de transport est un objet physique.
Confondre l'usage et la nature nous posera des problèmes ensuite si on veut
documenter avec plus de détails.

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

Bonjour Pierre-Yves,

Le 6 juillet 2016 à 16:39, Pierre-Yves Berrard <
pierre.yves.berr...@gmail.com> a écrit :

> Deux différences notables :
> On peut retrouver tous les éléments d'une route départementale par leur
> ref, pas pour une ligne de transport.
>
Peux-tu m'expliquer pourquoi ?

Que ce soit la D31 ou la L6 ca reste une ref, non ?
On peut retrouver la D31 dans plusieurs départements, la L6 sur plusieurs
réseaux de transport en commun.

La ligne de transport, comporte d'autres éléments, comme la position des
> arrêts.
>
La route départementale a des tronçons de route, mais aussi des bornes, des
panneaux, des boucles de comptages...



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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

Christian,

Ok avec ton point de vue, la relation complexifie pas mal le traitement des
données.
Comment ça se passe quand un tronçon partage plusieurs ref ? cf autoroute
avec les Axx nationaux et les Exx européens.

Elles aident aussi pour la maintenance et la pérennité.
Le jour où la ref change, il faut être sur qu'elle soit modifiée partout où
elle apparait. Si elle n'est posée que sur une relation, elle ne doit être
modifiée qu'à un endroit unique.
Il y a, à peu près, 9 chances sur 10 que l'ancienne ref reste sur le petit
segment que personne n'aura vu si on le répète sur tous les segments.

Relation ou pas, l'objet logique "départementale" peut être cassé dans tous
les cas.
Par ailleurs, pour l'état de santé de la N4, on peut plutôt blâmer les
contributeurs peu regardants que la relation en elle-même.

Question connexe : quelle différence vous faites entre une route
départementale et une ligne de transport en commun ?
Moi aucune, pourtant la seconde est très rarement représentée autrement
qu'avec une relation.


A+


*François Lacombe*

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

Le 6 juillet 2016 à 15:31, Christian Quest <cqu...@openstreetmap.fr> a
écrit :

> Le 06/07/2016 à 11:33, JB a écrit :
>
>> Bonjour,
>> Personnellement, je ne suis pas convaincu par le name=*. Pour moi, le ref
>> suffit largement, ce que tu mets dans name est juste une description de ce
>> ref.
>> Pour ma part, je ne suis pas fan des relations non plus. Si elles sont
>> élégantes sur le plan de la modélisation, elles sont peu accessibles aux
>> nouveaux mappeurs. Attendez-vous à avoir des doublons ref sur la relation +
>> ref sur certains tronçons.
>> JB.
>>
>>
> Et j'espère bien qu'on en aura des doublons de ref car si l'objectif en
> créant ces relations est de supprimer les tags communs, pourquoi s'arrêter
> au ref=*, pourquoi ne pas virer aussi les highway=*... (je pousse à
> l'extrême pour montrer le problème).
>
> L'immense majorité des outils qui utilisent les données OSM ne sauraient
> plus faire un rendu correct voire un calcul d'itinéraire.
>
> Ces relations ne me semble pas une super idée, on est pas loin de la
> notion de collections.
>
> Si l'on veut obtenir l'ensemble des tronçons composant la départementale 1
> dans le Val de Marne et bien une requête overpass le fait sans problème (
> http://overpass-turbo.eu/s/hal), pas besoin de relation qui sera très
> souvent cassée pour cela.
>
> Je m'étais amusé à créer une relation pour quelques route nationales (pour
> garder trace de ces routes mythiques qui passent en départementales)... à
> quoi ressemble-t-elle après plusieurs années d'existence ?
>
> Exemple avec la N4: http://www.openstreetmap.org/relation/2307408
>
> Et une liste des network=FR:N-road http://overpass-turbo.eu/s/ham
>
>
> Pour le name, il ne doit pas servir à décrire et ne devrait pas être
> penser pour être parsé, c'est le rôle des tags de fournir une description
> sémantique non ambigue, name sert à nommer ce qui porte un nom (exemple
> avec la Route Napoléon).
>
>
> Bref, pas chaud pour ces relations...
>
> Pour info, il y a une analyse osmose qui aide à trouver les différences
> entre OSM et Route500... et donc les manques potentiels dans OSM (attention
> Route500 peut aussi se tromper ou ne pas être à jour).
>
> --
> 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] Tag 'network' et 'name' pour une relation de type route départementale

2016-07-10 Thread François Lacombe

Bonsoir JB

Le 10 juillet 2016 à 20:40, JB  a écrit :

>
> TLDR : mauvaise foi ou aveuglement ? De moi, ou des autres ?
>

Ni l'un ni l'autre, on est juste pas d'accord sur certaines idées.
On devrait arriver à s'en remettre, tu ne crois pas ?

Chacun a bien donné son point de vue, si sa peut aider topographe fou dans
sa réflexion c'est tant mieux (bon courage !)

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

2016-07-10 Thread François Lacombe

Bonsoir à tous,

Le 7 juillet 2016 à 01:22, Christian Quest  a
écrit :

> Pour ça on a :
> - ref pour le Axx
> - int_ref pour le Exx
>

Ok

Mouais... pour le changement vu qu'on a de très fortes chances que la
> relation soit cassée quelque part, il sera toujours préférable de faire une
> requête overpass pour n'oublier aucun petit bout. Changer uniquement le ref
> sur la relation c'est un peu utopique malheureusement.
>



> Oui, c'est pour ça que j'ai donné l'exemple... les relations se cassent
> très facilement et si on ne jardine pas en permanence se baser uniquement
> dessus n'est malheureusement pas fiable.
>

Il y a pourtant tous les contours de communes qui sont décris comme ça.
Personne ne serait d'accord pour indiquer le nom de chaque commune sur les
tronçons de limite pour utiliser une requête overpass de la même manière.


>
> Question connexe : quelle différence vous faites entre une route
>> départementale et une ligne de transport en commun ?
>> Moi aucune, pourtant la seconde est très rarement représentée autrement
>> qu'avec une relation.
>>
>>
> Un tronçon de route ne compte qu'un ref (pour les Exx c'est un tag séparé
> qui décrit autre chose) alors qu'un tronçon de rue peut voir passer
> plusieurs lignes de bus ou autres itinéraires en tout genre.


C'est une hypothèse de départ que je ne partage pas.
Accordons-nous sur ce désaccord :)


> C'est pour cela que les relations sont adaptées aux transports en commun.
>
> On voit par ces multiples itinéraires combien les relations sont fragiles
> et complexe à maintenir... il suffit de voir le roman sur les panneaux M12
> ;)
> Imaginez la question "comment je fait pour indiquer que ce tronçon fait
> partie d'une départementale"...
>

Autant on ne tague pas pour le rendu, mais je n'aime pas les modélisations
pour les outils.

Investir dans des outils performants est plus pérenne que de répéter x fois
une information sur des milliers d'objets pour obtenir une simplicité
éphémère.
Utopie ou réalité, je ne suis pas légitime pour le dire.

La proposition ressemble pour l'instant beaucoup trop à la logique de
> "collection" et les arguments en faveur n'ont rien de nouveau
> (maintenabilité, élimination de redondance, etc) mais lors des discussions
> précédentes du même type, la conclusion avait été en défaveur des relations.
>

Pourquoi on en discute de cette façon aujourd'hui alors ?

Plusieurs voix ont dit la même chose quand il a s'agit de donner plus de
détails sur les lignes électriques il y a ~ 1 an.
Résultat, aujourd'hui le gouvernement allemand finance une initiative (
scigrid.de pour ne pas la nommer) et ils nous motivent énormément pour
rendre le réseau routable via des relations.
Cf http://scigrid.de/posts/2015-Jul-02_power-relations-in-openstreetmap.html

Si on applique votre vision des routes départementales, on devrait répéter
le nom des circuits de transport électrique sur tous les tronçons de file
de pylônes et de câbles souterrains. Ça ne serait clairement pas
maintenable, mais très simple dans l'approche.


A+

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

Hello,

Bonne initiative, ça va en effet permettre de significativement améliorer
la qualité des données de routage, avec un bon impact sur les rendus
routiers

Deux remarques pour amener de l'eau a ton moulin :
Point 1.2 : tu devais vouloir parler de l'INSEE région ? Inutile selon moi,
c'est bien un réseau départemental. Si on veut l'INSEE région, on le trouve
via l'INSEE du département
Point 2.3 : En effet, il ne faut pas refonder inutilement l'info et cette
solution de passer par network=* est la meilleure sur ce plan.

Autre chose : il faudrait utiliser operator=* pour indiquer l'exploitant,
idéalement sur chaque segment de route, puisque l'exploitation des tronçons
urbain peut être délégué aux villes.

A+

François
Le 6 juil. 2016 12:25 AM, "LeTopographeFou"  a
écrit :

> Bonjour,
>
> J'ai attaqué un imposant chantier visant à améliorer la prise en compte
> des Routes Départementales (RD) françaises dans OSM. Ce chantier vise à :
>
>1. Faire qu'il y ait une relation par RD par département (ex :
>http://www.openstreetmap.org/relation/6335278)
>2. Vérifier et corrigé le tracé des RD
>
> Le tout étant fait *à la main* (j'insiste sur le fait qu'il n'y a pas
> d'automate) en comparant les données OSM avec Route500. A ce jour j'ai fais
> les Yvelines et attaque l'Essonne. Aucune des RD n'avait de relation ad-hoc
> et certaines n'étaient carrément pas (ou incomplètement) référencées par
> leurs champ ref=*. Donc je les attaque une à une avec de belles trouvailles.
>
> Pour le moment je mets 4 tags à chaque relations (cf.
> http://www.openstreetmap.org/relation/6335278) mais je ne trouve pas cela
> très optimal d'où deux points à vous soumettre :
>
>1. Il faudrait en profiter pour mettre un tag 'network'. Pour info les
>RN ont visiblement un tag 'network=FR:n-road'. Afin de coller avec la
>logique utilisées aux EU j'ai deux propositions à faire :
>   1. Utiliser le code pays et le code INSEE du département (en
>   l’occurrence cela ferait 'FR:78')
>   2. Faire comme précédemment mais avec également le code INSEE du
>   département (en l’occurrence cela ferait 'FR:11:78)
>   3. Utiliser le code ISO 3166-2 (en l’occurrence cela ferait 'FR-78')
>2. Concernant le tag 'name' il y a des risques d'amalgames entre deux
>départements. Est-il judicieux d'y mentionner le nom du département ? Le
>hic est que, rigoureusement parlant, le nom "officiel" est 'Route
>départementale 29' sans autre fioriture
>1. Exemple 1 : 'Route départementale 29 (Yvelines)' => clair et
>   concis, facile à parser
>   2. Exemple 2 : 'Route départementale des Yvelines 29' => bof
>   3. Autre solution : ne rien faire, se dire que l'ajout de 'network'
>   suffit et que si amalgame il y a c'est un problème à gérer par
>   l'éditeur/l'app et non par le cartographe => c'est ma solution préféré 
> mais
>   autant réfléchir avant d'aller plus loin.
>
> A ce jour je ne vois pas de réponse ni dans les relations existantes ni
> sur le wiki. Qu'en pensez-vous ?
>
> LeTopographeFou
>
> ___
> 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] Tag 'network' et 'name' pour une relation de type route départementale

+1 Avec Francescu sur le is_in : on a les relations pour ça, à minima
l'analyse spatiale.

Également sur le fait de traduire une arborescence dans les tags, c'est pas
forcément adapté.
Ici la route départementale est effectivement dans un périmètre fermé
correspondant à la région, inutile de le faire transparaitre dans le code.
Ajouter ces infos dans les tags facilite la recherche c'est certain, mais
ça pose autant de problèmes pour la maintenance (cf fusion des régions).
Parce qu'on pourrait faire pareil avec le millefeuille : canton,
arrondissement... Et aussi on aurait du mal à traduire un cas où une route
quelle qu'elle soit est partagée sur plusieurs territoires.

Si des codes ISO sont disponibles, autant les utiliser sans inventer autre
chose
Et dans ces codes ISO si il y a le code pays, région ou autre, ca devient
le problème de l'ISO et pas celui d'OSM.

Il y a un compromis à trouver entre grouper des objets selon une valeur de
tag et utiliser une relation.
Ta proposition 1.5 est intéressante. Si je comprends bien, tu indiquerais
network=* sur cette méta-relation ?
Résultat quand deux départements fusionnent : un seul objet à modifier et
pas 300. L'édition de cet unique objet est cependant peu aisée vu le nombre
de membres potentiel (question d'habitude).
Idem sur les lignes de transport en commun... et tout autre réseau.

Par contre, est-ce ok de mettre des éléments routiers dans la relation
administrative du département, avec au moins les frontières et probablement
des écoles, des établissements sportifs et autres ?
C'est à dire que dès qu'on veut récupérer les contours d'un département, on
récupère vraiment tout si on ne filtre pas.


A+

François


*François Lacombe*

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

Le 6 juillet 2016 à 09:56, Francescu GAROBY <windu...@gmail.com> a écrit :

> Beau travail auquel tu t'attaques !
> J'ai moi-même commencé à faire la même chose avec les RT (routes
> territoriales) de Corse (anciennes RN). Je vais donc suivre attentivement
> cette discussion !
>
> Et sinon, je déconseille l'usage du tag "is_in", qui n'a plus de sens
> maintenant que les recherches géographiques sont possibles.
>
>
> Francescu
>
> Le 6 juillet 2016 à 09:15, Topographe Fou <letopographe...@gmail.com> a
> écrit :
>
>> Bonjour,
>>
>> Merci pour ce premier retour.
>>
>> Pour le 1.2 en effet je voulais parler des codes INSEE du département et
>> de celui de la région. Je partage également le point de vue que cela ne
>> contient pas plus d'informations dans le cas des RD. Mais si on se place
>> dans une logique d'arborescence alors il pourrait être pratique de faire
>> des recherches ou filtres par région. Hiérarchiquement parlant entre le
>> pays et le département il y a une région :). Il y a une solution
>> peut-être la plus logique (voir après).
>>
>> Proposition 1.4 : network=FR:78 (cad c'est une route départementale des
>> Yvelines en France) + is_in=FR:11:78 (cad c'est une relation dans le
>> département des Yvelines, région IDF, en France). Is_in est pas mal utilisé
>> aux EU, pour un statut assez vague.
>>
>> Proposition 1.5 : mettre les relations RD membre de la relation
>> Département pour créer explicitement la hiérarchie + network=FR:78
>>
>> Ok pour l'avis sur le 2.
>>
>> Pour le 'operator' je le préciserai sur le Wiki au moment de faire la
>> synthèse.  En ce qui me concerne cela sort de mon périmètre.
>>
>> LeTopographeFou
>> *De:*fl.infosrese...@gmail.com
>> *Envoyé:*6 juillet 2016 8:05 AM
>> *À:*talk-fr@openstreetmap.org
>> *Répondre à:*talk-fr@openstreetmap.org
>> *Objet:*Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de
>> type route départementale
>>
>> Hello,
>>
>> Bonne initiative, ça va en effet permettre de significativement améliorer
>> la qualité des données de routage, avec un bon impact sur les rendus
>> routiers
>>
>> Deux remarques pour amener de l'eau a ton moulin :
>> Point 1.2 : tu devais vouloir parler de l'INSEE région ? Inutile selon
>> moi, c'est bien un réseau départemental. Si on veut l'INSEE région, on le
>> trouve via l'INSEE du département
>> Point 2.3 : En effet, il ne faut pas refonder inutilement l'info et cette
>> solution de passer par network=* est la meilleure sur ce plan.
>>
>> Autre chose : il faudrait utiliser operator=* pour indiquer l'exploitant,
>> idéalement sur chaque segment de route, puisque l'exploitation des tronçons
>> urbain peut être délégué aux villes.
>>
>> A+
>>
>> François
>> Le 6 juil. 2016 12:25 AM, "LeTopographeFou" <letopographe...@gmail.com&g

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

Le 6 juillet 2016 à 11:33, JB  a écrit :

> Pour ma part, je ne suis pas fan des relations non plus. Si elles sont
> élégantes sur le plan de la modélisation, elles sont peu accessibles aux
> nouveaux mappeurs. Attendez-vous à avoir des doublons ref sur la relation +
> ref sur certains tronçons.
>

Vu la quantité de données croissante, les nouveaux mappeurs vont de plus en
plus devoir s'adapter à une modélisation qui reste stricte pour organiser
toute cette connaissance.
On ne peut pas se passer des relations, mais on est pas obligé de commencer
par ce domaine quand on arrive sur osm.

Par contre sur la redondance ref sur le chemin et sur la relation, je
croyais que c'était nécessaire pour le rendu ? (i.e mapnik ne sait pas
aller chercher dans la relation pour dessiner le chemin et ne sait pas
rendre des relations sur la base de la géométrie de ses membres).
A moins que ça ait changé ou que je me trompe complètement ?

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

Re: [OSM-talk-fr] Annonce de sortie : MapContrib 0.10.0

2016-08-06 Thread François Lacombe

Le 2 août 2016 à 23:29, Vincent Bergeot  a écrit :

> Bonjour,
>
> j'ai du coup tenté sur un autre thème : https://www.cartes.xyz/t/
> 0c0458-Test_Francois
> avec la requête suivante
> (  node["power"="substation"]["substation"="minor_
> distribution"]["operator"!~"."]({{bbox}});
>   way["power"="substation"]["substation"="minor_
> distribution"]["operator"!~"."]({{bbox}});
> );
>
> out body meta;
> >;
> out skel qt;
>
> et un déclenchement de la requête au zoom 12
>
> cela passe mieux mais cela n'a pas la même "ampleur" que la requête que tu
> souhaites faire sur la france (peut-être à essayer avec le cache qui
> s'exécute sur l'ensemble du globe si la requête prend moins de 3 minutes et
> 1MO de données). j'ai fait ce test (il faut attendre que le cache se
> constitue : https://www.cartes.xyz/t/d34a75-Test_Francois_avec_cache)
>
> De plus, nous n'avons pas la possibilité aujourd'hui d'afficher "meta"
> (j'ai ouvert une issue pour cela : https://github.com/MapContrib/
> MapContrib/issues/196)
>

Bonjour Vincent,

Je n'avais pas envisagé l'utilisation du bbox et c'est une bonne idée.
L'approche est un peu différente, je pensais faire la requête au niveau
national pour cibler les zones sur lesquelles travailler (ca se rapproche
un peu d'osmose)
Ici on s’intéresse à une zone pour voir si il n'y a pas des manques.

Si sa peut accélérer les requêtes, pourquoi pas, je change mon fusil
d'épaule.


> D'une manière générale, il faudrait éliminer toutes les occasions qui
> forcent l'utilisateur à quitter la carte (la connexion par exemple)
> Parce qu'on peut attendre pour charger un thème donné, et le fait de se
> connecter envoie vers OSM avant d'avoir à tout recharger une seconde fois,
> avec souvent des erreurs "too many requests".
>
> Reste à savoir si ca n'est pas une contrainte d'OAuth
>
>
> effectivement, pouvoir se connecter sans relancer la requête pourrait
> éviter quelques "too many request" -> https://github.com/MapContrib/
> MapContrib/issues/197
>

Merci pour la sig, je passerai par github à l'avenir


Bonne journée

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

Re: [OSM-talk-fr] Changement de nom réseau / opérateurs suite changement de type de regroupement de communes

2016-08-06 Thread François Lacombe

Bonjour à vous,

Concernant le changement de nom d'ERDF, je remplace à la mano les anciennes
valeurs que je vois au cours de mes éditions
Il faudrait un changement massif, mais c'est plutôt compliqué, pas le temps
en ce moment de prendre le lead dessus.
Il y a aussi wikidata, mais tous les consommateurs ne le prennent pas en
charge.

L'action la plus concrète a été de transformer mes requêtes overpass où on
trouvait des operator=ERDF en operator~"ERDF|Enedis"

Dans le cas que vous soulevez, on est encore chanceux que ca soit fait à
iso-périmètre
C'est à dire que l'entité d'origine ne se scinde pas en n EPIC ou ne
transmet pas une partie de son patrimoine à une autre structure :)


A+

*François Lacombe*

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

Le 6 août 2016 à 14:33, <osm.sanspourr...@spamgourmet.com> a écrit :

> J'aime beaucoup la page Wikipédia qui annonce un budget 2011 pour une
> entité datant de 2015.
>
> Car oui comme dit la CUB est devenue Bordeaux Métropole.
>
> Sur https://www.wikidata.org/wiki/Q1117116 les noms hormis en français et
> occitan sont toujours basés sur la CUB.
>
> si on avait les ref:Q1117116 on n'aurait pas à les changer mais il faut
> adapter les outils. Car un tel code est sujet à typo et côté ergonomie
> homme-machine on a vu mieux.
>
> L'autre CUB (Communauté Urbaine de Brest) est devenue Brest Métropole
> Océane puis plus simplement Brest Métropole.
>
> Je n'ai pas trouvé de traces de CUB dans le coin. Et name:bm ce n'est pas
> du bordelais mais du bambara.
>
> Je serais plutôt pour un remplacement systématique.
>
> Tu vas aussi pouvoir changer les couleurs des lignes de bus ;-)
> Jean-Yvon
>
> Le 06/08/2016 à 12:54, Frédéric Rodrigo - fred.rodr...@gmail.com a écrit :
>
> Le 06/08/2016 à 11:43, lenny.libre a écrit :
>
>
> Bonjour
>
> Il y a quelque temps, j'ai vu une discussion sur le changement de nom
> "Enedis"
>
> Je me pose la question pour les réseaux et opérateurs qui changent de nom
> lors des changements de type des regroupements de communes.
>
> Par exemple : la "CUB" (Communauté Urbaine de Bordeaux) est devenue
> "Bordeaux Métropole" - https://fr.wikipedia.org/wiki/
> Bordeaux_M%C3%A9tropole
>
> - Cela entraine le changement de nom du réseau de transport "TBC" devient
> "TBM" - http://www.infotbm.com/actualites/tbc-devient-tbm-
> vos-lignes-changent-de-couleurs
>
> d’après taginfo :
>
>   * 2 534 tag "network=TBC" et variantes + 176 "network=VCUB"et 2
> "CUB"
>   * 342 "operator=TBC"
>   * 6 "name contenant "TBC"
>
> - de même pour l'opérateur : https://fr.wikipedia.org/wiki/
> Keolis_Bordeaux_M%C3%A9tropole#Pr.C3.A9sentation
>
>   * dans taginfo, on trouve des "operator=Keolis" génériques (non
> limités à Bordeaux) et 1 "Keolis Bordeaux"
>
> Je suppose que nous allons trouver la même chose dans d'autres ...
>
> Comment faut-il faire ?
> - au fil de l'eau (je commence quand je connais, mais cela ne sera pas
> uniforme)
> - en une fois (je ne sais pas faire et que faire avec les nouveaux qui
> vont continuer à mettre "TBC")
> - Osmose (?)
>
> Concernant Osmose il faudrait déjà qu'il propose les nouveaux nom sur les
> données proposées à l'intégration.
> C'était déjà le cas pour le changement de nom de TBC en TBM.
> Ton mail m'a poussé à modifier les autres intégrations de données
> concernant Bordeaux Métropole.
>
> Il reste également la question la référence, actuellement c'est
> ref:FR:CUB.
>
> Frédéric.
>
>
> ___
> 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] Changements de location=* avec location:transition=yes

2016-06-30 Thread François Lacombe

Bonjour Stéphane,

Non je ne pense pas, parce que le but de cette liste de valeurs équivalente
est de donner des repères pour faire la correspondance avec ce qui était
déjà cartographié.
Chacun trouvera utile ou non d'utiliser la nouvelle valeur.

Par contre je vais indiquer sur
http://wiki.openstreetmap.org/wiki/Tag:pole%3Dtransition qu'il y a une
valeur plus adaptée.
Le volume a pris +1000 depuis l'année dernière :(

François


*François Lacombe*

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

Le 30 juin 2016 à 20:11, Stéphane Péneau <stephane.pen...@wanadoo.fr> a
écrit :

> Ok, c'est noté.
>
> Mais dans ce cas, est-ce qu'il ne faudrait pas supprimer les autres
> possibilités de cette page :
> http://wiki.openstreetmap.org/wiki/Tag:location:transition%3Dyes
> C'est là que j'ai pris les différentes solutions.
>
> Stf
>
>
> Le 29/06/2016 à 23:04, François Lacombe a écrit :
>
> Bonsoir Stéphane,
>
> En fait les 3 solutions que tu mentionnes sont équivalentes, elles
> correspondent à différents états de la réflexion.
>
> La seule chose recommandée aujourd'hui, avec le vote de
> location:transition, est power=pole + location:transition=yes
> Tout le reste doit être remplacé à terme.
>
> Il faudrait que je traduise la page du wiki pour location:transition, les
> autres clés n'ont normalement pas de page (et n'en auront jamais du coup).
>
> A+
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux <http://www.twitter.com/InfosReseaux>
>
> Le 29 juin 2016 à 12:08, Stéphane Péneau <stephane.pen...@wanadoo.fr> a
> écrit :
>
>> Bonjour François,
>>
>> Dans ce genre de cas :
>>
>> http://wiki.openstreetmap.org/wiki/File:French_distribution_line_with_transition.jpg
>>
>> Quelle est la différence entre :
>>
>> power=pole
>> pole=transition
>>
>> et
>> power=pole
>> location:transition=yes
>>
>> et
>> power=pole
>> pole=location_transition
>>
>> Qu'est-ce qui est recommandé ? Je trouve ça un peu bizarre d'avoir 3
>> choix possibles pour un même cas.
>>
>> Stf
>>
>>
>>
>> Le 13/02/2016 à 16:08, François Lacombe a écrit :
>>
>>> Bonjour à tous,
>>>
>>> Une petite information que je crois avoir oublié de diffuser ici : la
>>> proposition sur les changements de localisation pour des objets
>>> linéaires tels que les pipelines, câbles électriques ou câbles
>>> sous-marin a récemment été approuvée par vote sur le wiki.
>>> http://wiki.openstreetmap.org/wiki/Proposed_features/Location_transitions
>>>
>>> Une clé unique permet désormais de documenter les endroits où ces
>>> objets passent de l'aérien au souterrain, du sous-marin au terrestre,
>>> etc... et est particulièrement utile lorsque l'on ne peut pas suivre
>>> l'objet qui continue sous terre ou sous l'eau.
>>> http://wiki.openstreetmap.org/wiki/Tag:location:transition%3Dyes
>>>
>>> Tout cela est en anglais, l'utilisation est très simple :
>>> Il suffit d'ajouter location:transition=yes sur un nœud au droit du
>>> changement de localisation, que les deux parties soient connues ou
>>> pas.
>>>
>>> Exemples :
>>>
>>> https://www.openstreetmap.org/node/1936741197#map=19/45.93596/6.15185=D
>>>
>>> https://www.openstreetmap.org/node/2273329828#map=19/46.11414/6.05299=D
>>>
>>> Cela correspond au clés/valeurs plus spécifiques
>>> tower=air_to_ground
>>> tower=transition
>>> pole=transition
>>> tower=location_transition
>>> pole=location_transition
>>> et autres...
>>> Elles peuvent être remplacées, avec parcimonie et au cas par cas en
>>> étant bien sûrs de ce que vous faites.
>>>
>>> Bien que le domaine soit très technique, il est possible de s'en
>>> servir sur à peu près tout.
>>> On évite ainsi l'utilisation d'un fixme=continue ou assimilé lorsque
>>> l'on perd de vue quelque chose.
>>> On s'attend par contre à trouver une valeur pour location=* sur tous
>>> les objets connectés au nœud qui portent location:transition=yes
>>>
>>>
>>> Bon week end
>>>
>>> François
>>>
>>>
>>> --
>>> François Lacombe
>>>
>>> fl dot infosreseaux At gmail dot com
>>> www.infos-reseaux.com
>>> @InfosReseaux
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>>
>> ___
>> 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
>
>
>
> ___
> 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] Changements de location=* avec location:transition=yes

2016-06-30 Thread François Lacombe

Bonjour Jean-Yvon,

Le 30 juin 2016 à 21:55,  a écrit :

> S'il y a une valeur à favoriser, il vaut mieux mettre "Depreciated values"
> si tel est le cas car équivalent c'est équivalent.
>
Le problème est qu'il s'agissait d'un vote à la base.
Avec le temps j'ai pu m’apercevoir qu'écrire "equivalent values" et "can be
carefully replaced" au lieu de "deprecated" and "must be changed
immediatly" pouvait faire peur à moins de monde.

Dans l'absolu, il n'y a pas de valeurs dépréciées, tout le monde utilise
les tags qu'il veut.
Donc il faut convaincre le plus de monde de faire autrement... et pas les y
obliger.
Un bon tag se suffit à lui-même, le reste - si ce n'est une bonne
explication et visibilité - est superflu.

Bon, la template wiki ne proposant rien d'autre que "Deprecated" comme
valeur d'abandon pour une valeur, c'est ce que j'ai indiqué sur l'infobox
de pole=transition.

Et si tu fais des requêtes sur les objets, tu peux proposer aux auteurs de
> modifier ou de modifier à leur place (car il peut y avoir des consommateurs
> de données utilisant l'ancien format, si tu contactes tous les auteurs tu
> devrais avoir un retour en cas d'utilisation).
>
Pour le coup c'est long, et je n'ai pas cette patience, il y a des dizaines
de milliers d'objets, des centaines de contributeurs.
Quand je trouve un poteau avec pole=transition, je change pour
location:transition sans me poser de question hormis celle de savoir si un
câble va sous terre.

A+

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

Re: [OSM-talk-fr] distance entre deux points sur une route

2016-06-29 Thread François Lacombe

Bonjour Adrien,

A mon sens c'est un calcul de distance loxodromique entre chaque nœud, de
chaque portion de véloroute qui composent le chemin à parcourir.
https://fr.wikipedia.org/wiki/Loxodromie

Concrètement, voici un bout de PHP qui te donne la distance entre deux
points dont tu connais le lat/lon
Tu n'as plus qu'à faire la somme de tous tes segments pour avoir la
distance totale

$l = 6366 * 2 * asin(
sqrt(
pow( sin((deg2rad($lat)-deg2rad($ll[1]))/2) ,
2) + cos(deg2rad($lat))*cos(deg2rad($ll[1]))* pow(
sin((deg2rad($lng)-deg2rad($ll[0]))/2) , 2)
)
);

Où $lat et $lng sont les coordonnées de ton point B et $ll[0] et $ll[1]
celles de ton point A.
Cette formule a un défaut : elle ne tient pas compte de l'altitude des
points, réputée négligeable ici.


A+

*François Lacombe*

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

Le 29 juin 2016 à 20:46, adrien <pe...@adrieng.fr> a écrit :

> Bonjour,
>
> J'aimerais connaître la distance entre deux points sur une relation
> route=bicycle,en l'occurence la distance entre Nantes et Blain sur la
> Vélodyssée.
>
> Je suppose que c'est facilement faisable, mais je sèche complètement sur
> comment faire, et quel outils utiliser…
>
> Si vous avez des pistes, je vous en serait reconnaissant.
>
> Bonne soirée
>
> Adrien
>
>
> ___
> 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] Changements de location=* avec location:transition=yes

2016-06-29 Thread François Lacombe

Bonsoir Stéphane,

En fait les 3 solutions que tu mentionnes sont équivalentes, elles
correspondent à différents états de la réflexion.

La seule chose recommandée aujourd'hui, avec le vote de
location:transition, est power=pole + location:transition=yes
Tout le reste doit être remplacé à terme.

Il faudrait que je traduise la page du wiki pour location:transition, les
autres clés n'ont normalement pas de page (et n'en auront jamais du coup).

A+

*François Lacombe*

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

Le 29 juin 2016 à 12:08, Stéphane Péneau <stephane.pen...@wanadoo.fr> a
écrit :

> Bonjour François,
>
> Dans ce genre de cas :
>
> http://wiki.openstreetmap.org/wiki/File:French_distribution_line_with_transition.jpg
>
> Quelle est la différence entre :
>
> power=pole
> pole=transition
>
> et
> power=pole
> location:transition=yes
>
> et
> power=pole
> pole=location_transition
>
> Qu'est-ce qui est recommandé ? Je trouve ça un peu bizarre d'avoir 3 choix
> possibles pour un même cas.
>
> Stf
>
>
>
> Le 13/02/2016 à 16:08, François Lacombe a écrit :
>
>> Bonjour à tous,
>>
>> Une petite information que je crois avoir oublié de diffuser ici : la
>> proposition sur les changements de localisation pour des objets
>> linéaires tels que les pipelines, câbles électriques ou câbles
>> sous-marin a récemment été approuvée par vote sur le wiki.
>> http://wiki.openstreetmap.org/wiki/Proposed_features/Location_transitions
>>
>> Une clé unique permet désormais de documenter les endroits où ces
>> objets passent de l'aérien au souterrain, du sous-marin au terrestre,
>> etc... et est particulièrement utile lorsque l'on ne peut pas suivre
>> l'objet qui continue sous terre ou sous l'eau.
>> http://wiki.openstreetmap.org/wiki/Tag:location:transition%3Dyes
>>
>> Tout cela est en anglais, l'utilisation est très simple :
>> Il suffit d'ajouter location:transition=yes sur un nœud au droit du
>> changement de localisation, que les deux parties soient connues ou
>> pas.
>>
>> Exemples :
>>
>> https://www.openstreetmap.org/node/1936741197#map=19/45.93596/6.15185=D
>>
>> https://www.openstreetmap.org/node/2273329828#map=19/46.11414/6.05299=D
>>
>> Cela correspond au clés/valeurs plus spécifiques
>> tower=air_to_ground
>> tower=transition
>> pole=transition
>> tower=location_transition
>> pole=location_transition
>> et autres...
>> Elles peuvent être remplacées, avec parcimonie et au cas par cas en
>> étant bien sûrs de ce que vous faites.
>>
>> Bien que le domaine soit très technique, il est possible de s'en
>> servir sur à peu près tout.
>> On évite ainsi l'utilisation d'un fixme=continue ou assimilé lorsque
>> l'on perd de vue quelque chose.
>> On s'attend par contre à trouver une valeur pour location=* sur tous
>> les objets connectés au nœud qui portent location:transition=yes
>>
>>
>> Bon week end
>>
>> François
>>
>>
>> --
>> François Lacombe
>>
>> fl dot infosreseaux At gmail dot com
>> www.infos-reseaux.com
>> @InfosReseaux
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> ___
> 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 applis mobiles spécialisées

2017-01-26 Thread François Lacombe

Bonsoir Florian,

Merci pour cette proposition, il y a deja quelques sujets qui pourraient se
préter à l'exercice.

Je ne connais pas la structure du projet OSM Contributor, mais est-ce que
le fork est obligatoire ?
Pour pratiquer JOSM et ses multiples fonctionnalités, un certain nombre de
fichiers de configuration facilement manipulables permettent de
completement tansformer l'outil.
Ca serait surement plus facile à gérer, à condition qu'ajouter de tels
fichiers soit abordable

Fabriquer des apk distincts n'est pas compliqué à la suite de ca (qu'on
fork ou qu'on définisse des configurations distinctes de la même
application de base).

Qu'en pensez-vous ?

*François Lacombe*

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

Le 26 janvier 2017 à 17:57, Florian LAINEZ <winner...@free.fr> a écrit :

> Salut,
>
> Vous connaissez sûrement nos sympathiques amis de Jawg Maps
> <https://www.jawg.io/> et leur appli open source OSM contributor
> <https://www.jawg.io/osm-contributor-v3/>.
> Suite à une discussion à Décryptagéo, Jawg nous propose de forker OSM
> contributor pour fabriquer des applis de contribution spécialisées sur un
> sujet précis.
>
> Concrètement nous devons définir quelques sujets prioritaires qu'ils
> peuvent traiter simplement et leur fournir les specs précises pour leur
> faciliter le boulot.
> Pour l'instant je pense aux arrêts de bus, aux bornes d'incendie, aux
> défibrillateurs et aux boites aux lettres de la Poste.
> *J'ai commencé le travail ici :
> https://annuel.framapad.org/p/forks-osm-contributor
> <https://annuel.framapad.org/p/forks-osm-contributor> *et votre
> contribution est bienvenue.
>
> Vous le savez peut-être, ce sujet me tient à cœur en ce moment : je suis
> persuadé que nous manquons d'outils de contribution mobile ultra simples
> pour élargir notre communauté (enlarge your community comme disent les
> américains).
>
> Mille merci à l'équipe de Jawg qui sont des véritables machines pour nous
> accompagner sur ce projet.
>
> --
>
> *Florian Lainez*
> @overflorian <http://twitter.com/overflorian>
>
> ___
> 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 applis mobiles spécialisées

2017-01-26 Thread François Lacombe

Bonsoir Loic

Le 26 janvier 2017 à 20:00, loic ortola  a écrit :

> @François: en fait les presets josm sont inutilisables car XML based
> et contiennent toutes les ressources (images, etc...) en local. Les
> parseurs XML sont désastreux sur Android.
>

Attention, ça n'étais pas mon propos.
Je prenais le principe des presets en exemple parce qu'on a bien 1 appli =>
moult cas d'usages avec les presets que chacun peut compléter.

Du reste JOSM est une chose, OSM contributor en est une autre.


>
> Après discussion avec Florian, il aurait aimé qu'on publie aussi
> quelques applications justement très ciblées (différentes d'OSM
> Contributor), et moi ca ne me pose aucun soucis. Pas forcément de fork
> à faire, mais je préfère faire un fork plutôt que de me retrouver avec
> 400 branches sur le repository OSM Contributor. Ce sera plus facile à
> maintenir.
>

Ca pourrait se passer différemment.
On va avoir plein d'applications qu'il va bien falloir maintenir avec un
principe fonctionnel qui ne change que très peu.

Donc 400 projets séparés, avec sans cesse les mêmes commit pour diffuser
des patchs sur les 400 instances.

On doit bien pouvoir trouver un compromis non ?

D'ailleurs sur JOSM, ca ne se passe pas comme ça et l'expérience semble
concluante.


> D'où les questions, quels sont les 3 ou 4 presets que vous voudriez
> avoir à vos côtés sur votre mobile?
>

Ce dont il faut se méfier est ceux qu'on a pas encore envie d'avoir en fait
;)


C'est une bonne idée par ailleurs, les applis mobiles sont une lacune d'OSM
d'après plusieurs retours


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

Re: [OSM-talk-fr] Centrales électriques

2017-01-21 Thread François Lacombe

Bonjour Jérôme,

Merci pour cette mise en valeur, c'est très réussi (ne serait-ce que pour
débusquer les manques dans la base) !

Lorsqu'on a yes sur plant:output:electricity, c'est que la valeur est
inconnue (et qu'elle peut donc être considérée comme la plus faible).
Le fait de connaitre la puissance installée est encore bien souvent du bon
vouloir de l'exploitant. Des clés avec yes peuvent le rester longtemps
avant que la valeur ne soit connue.

Exemple ici : https://www.openstreetmap.org/relation/5489802
Il ne me semble pas que la puissance soit publique


*François Lacombe*

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

Le 18 janvier 2017 à 12:28, <osm.sanspourr...@spamgourmet.com> a écrit :

> Il me semble raisonnable de faire l'hypothèse que yes=le plus petit.
>
> Car il vaut mieux afficher que ne pas afficher et les petits équipements
> sont ceux les moins facilement renseignables.
>
> Un truc trop petit, tu veux le préciser si tu connais alors qu'un truc
> carrément absent...
>
> Peut-être avec une couleur estompée pour montrer que ce n'est pas une
> puissance connue ?
> Jean-Yvon
>
> Le 18/01/2017 à 00:26, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
>
> Le problème c'est que j'affiche que s'il y a une valeur pour
> plant:output:electricity=*. là il y a yes et pas la puissance en watts.
> sinon avec yes impossible de savoir si c'est une énorme centrale ou un
> petit panneau solaire et donc comment l'affiché au milieu des autres qui
> ont une taille proportionnelle à leur puissance?.
>
>>
>> Bonne soirée
>>
>> Adrien
>>
>
>
> ___
> 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] Tarif des péages

2017-02-20 Thread François Lacombe

Bonjour,

Je pense que là nous sommes dans une problématique à long terme ingérable.
> En effet il faudrait que la source soit les sociétés d'autoroutes elles
> mêmes!
> Pourquoi c'est simple la multiplicité des couples entrée-sortie. Par
> contre des péages sur des ouvrages d'art est possible et en soit pertinent
> car aisément modifiable.
>

+1, je ne suis pas sur qu'OSM soit le plus adapté pour contenir ces
informations.
Cartographier et qualifier la structure du péage ok, mais ajouter ce genre
d'infos devrait être fait en jointure basée sur une référence métier.

OSRM peut-il utiliser des infos d'une source externe à solliciter avec une
telle référence ?

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

Re: [OSM-talk-fr] Tarif des péages

2017-02-20 Thread François Lacombe

Le 20 février 2017 à 11:44, Christian Quest  a
écrit :

> par contre les péages ponctuels (je pense aux ponts) ça serait pas idiot,
> mais je vois aussi la complexité pour les différentes catégories.
>

A mon avis c'est identique aux péages d'autoroute.
Et les péages des ponts peuvent évoluer à des rythmes plus rapides que les
autoroutes mêmes, varier en fonction de la saison, avoir des tarifs abonnés
/ résidents, etc...

Si on indique ces tarifs là, il faudra mettre les tarifs des bacs et
ferries qui assument la même fonction, et ce sera probablement terrible à
maintenir

Aucun tarif dans OSM reste une valeur sûre :)


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

[OSM-talk-fr] Extraire une géométrie représentative d'une relation

2016-08-22 Thread François Lacombe

Bonjour à tous,

Avec la récente mise en place et adoption croissante d'open event database,
je me pose une question que certains ont déjà du résoudre.

Existe-t-il une méthode générique pour convertir une relation OSM en
geojson ?
Cela reviendrait à convertir la relation en géométrie simple (points /
polyline).

Le besoin est d'attribuer une géométrie représentative à des événements
dégagés par des ouvrages décrit avec une relation.
Après on peut les envoyer sur open event db.

Mais il peut y avoir des tonnes d'autres usages à cela, sans se limiter à
cet exemple.

J'aimerais éviter les scripts avec des if/else à rallonge pour cibler tel
ou tel type de relation, à la recherche de tel ou tel objet qui au final
n'est pas forcé de se trouver là où on l'attend, etc...


Merci par avance pour vos retours

François


--
*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Extraire une géométrie représentative d'une relation

2016-08-22 Thread François Lacombe

Bonjour Philippe, Guillaume,

Personne n'est a coté de la plaque ;)

Cependant, seule la méthode m’intéresse.
En effet il y a déjà quelques outils qui parviennent à présenter
graphiquement une relation mais j'ai besoin de l'implémenter de mon côté.

Relativement à l'exemple du résultat d'OSM.org. Il n'emploie pas une
géométrie unique. Il affiche tous les objets de la relation et c'est vite
le fouillis, en plus de devoir être découpé pour être intégré dans du
geojson.
Voir ici : http://www.openstreetmap.org/relation/5430194
Je m'attends à récupérer une ligne toute simple sans les deux polygones aux
extrémités. C'est la seule géométrie "simple" et représentative qu'on
puisse exploiter sans faire appel à des FeatureCollections ou autre.

Et ça me semble très dur de trouver une méthode générique qui puisse faire
cette synthèse parce qu'il semble qu'il y ait autant de possibilités que de
cas :'(

François

Le 22 août 2016 à 14:45, Philippe Verdy <verd...@wanadoo.fr> a écrit :

> Le site web OSM le fait déjà quand on "explore" une relation: ça
> télécharge un jeu de données JSON permettant le rendu vectoriel de l'objet
> sélectionné par dessus le fond de carte. La Wikipédie francophone le fait
> aussi sur ses cartes (mais elle requête son propre serveur pour obtenir
> aussi des POIs géolocalisés sur Wikipédia ou des photos géolocalisées sur
> Commons)
> Attention en cas d'inclusion dans un script web : l'API ne doit pas
> surcharger le serveur interrogé (on a vu le problème ces jours-ci sur
> Overpass API avec des centaines de milliers de requêtes par heure au lieu
> de quelques dizaines habituellement, deux serveurs Overpass API sont tombés
> plusieurs fois de suite, peut-être à cause d'un script d'un réseau
> publicitaire abusif ou d'une appli non-officielle type Pokemon).
> Bref gérer des caches sur votre serveur et éviter de faire des requêtes
> automatiques en boucle par le client sur chaque page web du site ou chaque
> page de l'appli mobile, respecter les protocoles !
>
>
> Le 22 août 2016 à 14:30, François Lacombe <fl.infosrese...@gmail.com> a
> écrit :
>
>> Bonjour à tous,
>>
>> Avec la récente mise en place et adoption croissante d'open event
>> database, je me pose une question que certains ont déjà du résoudre.
>>
>> Existe-t-il une méthode générique pour convertir une relation OSM en
>> geojson ?
>> Cela reviendrait à convertir la relation en géométrie simple (points /
>> polyline).
>>
>> Le besoin est d'attribuer une géométrie représentative à des événements
>> dégagés par des ouvrages décrit avec une relation.
>> Après on peut les envoyer sur open event db.
>>
>> Mais il peut y avoir des tonnes d'autres usages à cela, sans se limiter à
>> cet exemple.
>>
>> J'aimerais éviter les scripts avec des if/else à rallonge pour cibler tel
>> ou tel type de relation, à la recherche de tel ou tel objet qui au final
>> n'est pas forcé de se trouver là où on l'attend, etc...
>>
>>
>> Merci par avance pour vos retours
>>
>> François
>>
>>
>> --
>> *François Lacombe*
>>
>> fl dot infosreseaux At gmail dot com
>> www.infos-reseaux.com
>> @InfosReseaux <http://www.twitter.com/InfosReseaux>
>>
>> ___
>> 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] Extraire une géométrie représentative d'une relation

2016-08-23 Thread François Lacombe

En fait, je donnais un exemple et le but est de trouver une méthode pour
toutes les relations.
Toutes n'ont pas de membre avec le role line.

On peut se demander ce qu'est une géométrie représentative (je raisonne
tout haut)
Le périmètre qui encadre tous les membres par exemple, mais trop "grossier".
Ou alors la concaténation des plus gros membres de la relation
Il doit surement y avoir d'autres moyens de l'exprimer

Dans mon exemple, on devrait être capable de retrouver la forme de la ligne
qui constitue le plus gros de la relation en éliminant le "bruit" aux
extrémités provoqué par des objets proches les uns des autres au regarde de
l'étendue de la relation.
Mais surtout il ne faut travailler que sur la géométrie des membres, dès
qu'on passe aux attributs, ca revient à définir des règles spécifiques dont
je ne veux pas.

Pas sur que ce soit plus clair :)

*François Lacombe*

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

Le 22 août 2016 à 16:45, Christian Quest <cqu...@openstreetmap.fr> a écrit :

> Dans overpass une requête permet de ne sélectionner que les membres
> portant un certain rôle dans la relation:
>
> rel(5430194 <http://www.openstreetmap.org/relation/5430194>);
> way(r:"line");
> (._;>;);out skel;
>
> Après il faut en récupérer la version geojson...
>
> Le 22/08/2016 à 15:25, François Lacombe a écrit :
>
> Bonjour Philippe, Guillaume,
>
> Personne n'est a coté de la plaque ;)
>
> Cependant, seule la méthode m’intéresse.
> En effet il y a déjà quelques outils qui parviennent à présenter
> graphiquement une relation mais j'ai besoin de l'implémenter de mon côté.
>
> Relativement à l'exemple du résultat d'OSM.org. Il n'emploie pas une
> géométrie unique. Il affiche tous les objets de la relation et c'est vite
> le fouillis, en plus de devoir être découpé pour être intégré dans du
> geojson.
> Voir ici : http://www.openstreetmap.org/relation/5430194
> Je m'attends à récupérer une ligne toute simple sans les deux polygones
> aux extrémités. C'est la seule géométrie "simple" et représentative qu'on
> puisse exploiter sans faire appel à des FeatureCollections ou autre.
>
> Et ça me semble très dur de trouver une méthode générique qui puisse faire
> cette synthèse parce qu'il semble qu'il y ait autant de possibilités que de
> cas :'(
>
> François
>
> Le 22 août 2016 à 14:45, Philippe Verdy <verd...@wanadoo.fr> a écrit :
>
>> Le site web OSM le fait déjà quand on "explore" une relation: ça
>> télécharge un jeu de données JSON permettant le rendu vectoriel de l'objet
>> sélectionné par dessus le fond de carte. La Wikipédie francophone le fait
>> aussi sur ses cartes (mais elle requête son propre serveur pour obtenir
>> aussi des POIs géolocalisés sur Wikipédia ou des photos géolocalisées sur
>> Commons)
>> Attention en cas d'inclusion dans un script web : l'API ne doit pas
>> surcharger le serveur interrogé (on a vu le problème ces jours-ci sur
>> Overpass API avec des centaines de milliers de requêtes par heure au lieu
>> de quelques dizaines habituellement, deux serveurs Overpass API sont tombés
>> plusieurs fois de suite, peut-être à cause d'un script d'un réseau
>> publicitaire abusif ou d'une appli non-officielle type Pokemon).
>> Bref gérer des caches sur votre serveur et éviter de faire des requêtes
>> automatiques en boucle par le client sur chaque page web du site ou chaque
>> page de l'appli mobile, respecter les protocoles !
>>
>>
>> Le 22 août 2016 à 14:30, François Lacombe <fl.infosrese...@gmail.com> a
>> écrit :
>>
>>> Bonjour à tous,
>>>
>>> Avec la récente mise en place et adoption croissante d'open event
>>> database, je me pose une question que certains ont déjà du résoudre.
>>>
>>> Existe-t-il une méthode générique pour convertir une relation OSM en
>>> geojson ?
>>> Cela reviendrait à convertir la relation en géométrie simple (points /
>>> polyline).
>>>
>>> Le besoin est d'attribuer une géométrie représentative à des événements
>>> dégagés par des ouvrages décrit avec une relation.
>>> Après on peut les envoyer sur open event db.
>>>
>>> Mais il peut y avoir des tonnes d'autres usages à cela, sans se limiter
>>> à cet exemple.
>>>
>>> J'aimerais éviter les scripts avec des if/else à rallonge pour cibler
>>> tel ou tel type de relation, à la recherche de tel ou tel objet qui au
>>> final n'est pas forcé de se trouver là où on l'attend, etc...
>>>
>>>
>>> Merci par avance pour vos re

Re: [OSM-talk-fr] Extraire une géométrie représentative d'une relation

2016-08-24 Thread François Lacombe

Merci pour vos retour, j'ai essayé de mieux définir le besoin

Voyez ci-dessous

Le 23 août 2016 à 17:53, Topographe Fou  a écrit
:

> Bonjour
>
> Quid de l'algorithme de Douglas-Peucker ? C'est efficace pour éliminer le
> bruit. Quant à l'appliquer sur autre chose qu'une *unique* ligne *non
> fermée* cela demandera un peu d'adaptation.
>

Merci pour le nom, je ne connaissais pas :)

Ça s'approche oui, et si ce n'est pas le processus complet, en tout cas ça
peut aider

Le 23 août 2016 à 18:54, Christian Quest  a écrit :

> Je ne suis pas sûr que ça donne un résultat pertinent et surtout en ne
> définissant pas clairement ce que tu veux en sortie je pense qu'on peut
> sortir plein de choses bien variées. Si tu veux précisément la géométrie de
> la ligne sans les autres objets de la relation (même cas pour une ligne de
> bus) il faut filtrer sur le rôle et éventuellement le type de géométrie
> (linestring ou polygon).
>
Non vraiment je ne souhaite travailler que sur la géométrie, pas de
filtrage sur le rôle ou les attributs et que ça soit valide pour toute
relation.
Le rôle n'est pas représentatif de la géométrie mais plus de la fonction.
Pour faire un "dessin grossier" de ce à quoi ressemble une relation sur le
terrain, on ne vas pas regarder la fonction des éléments (la conduite
forcée issue d'un barrage peut mesurer 50m comme 10 km)

Pour la définition je pense à : "ne garder que les éléments qui ont des
dimensions à l'échelle de celles de la relation entière".
Pour une autoroute par exemple, on ne va pas garder les petites bretelles
qui sont négligeables mais celle-ci par exemple, un peu plus :
https://www.openstreetmap.org/way/83016524

Il faudrait préalablement assembler les segments de chemin avec des
attributs équivalents (ou avec les mêmes rôles) qui sont placés les uns à
la suite des autres pour obtenir les plus grands objets possibles avant de
filtrer sur leur taille.
Ici travailler en relatif sur les attributs/rôle pose moins de problème :
on compare les membres de la relation entre eux et on a pas besoin de
définir des règles absolues.

L'autoroute est d'ailleurs un bon exemple à bien des égards : le besoin est
de sortir l'itinéraire en supprimant tous les petits éléments de part et
d'autre en ne regardant que la géométrie de ces éléments.
Bon sous OSM, les relations sont uniquement constituées des voies
principales sans ajouter les péages et autres bretelles, mais vous voyez
l'esprit non ?

Il y a aussi une fonction "squelette" dans postgis, elle permet par exemple
> d'avoir une ligne médiane d'un polygone.
>
> Pour le placement de textes, c'est utile, ça permet d'avoir des textes qui
> suivent la forme globale plutôt que d'être placé à l'horizontal, mais je
> n'ai pas encore essayé d'utiliser ça pour les rendus.
>
Comme l'algo de topographe fou, ça peut être utile.

Bref, vaste sujet ;)
>
A plusieurs c'est quand même plus pratique pour réfléchir :)

A+

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

Re: [OSM-talk-fr] Trophées fondation EDF

2016-10-02 Thread François Lacombe

Bonjour Martin

Merci pour l'info, cela va concerner quelques initiatives ici

Pour ma part, ça serait tellement bien qu'EDF contribue en propre au lieu
de considérer ça comme de la com
Comme beaucoup d'entreprise par ailleurs...

Bonne journée
François

Le 2 oct. 2016 3:36 PM, "Martin Noblecourt"  a
écrit :

> Bonjour à tous,
>
> Je relaie sur cette liste l'appel à candidature des Trophées des
> associations EDF, qui a cette année une thématique "Solidarités numériques"
> : http://tropheesfondation.edf.com/
>
> Je pense qu'un certain nombre d'associations qui gravitent autour d'OSM
> (voir OSM-Fr directement ?) seraient tout à fait éligibles, et il y a
> encore peu de concurrence sur cette thématique ;-)
>
> Bonne chance à tous !
>
> (CartONG n'est pas éligible, budget trop important, donc on ne vous
> concurrencera pas ;-) )
>
> --
> [image: CartONG]
>
> Martin Noblecourt
> [image: Email:] m_nobleco...@cartong.org
> [image: Phone:] +33 (0)4 79 26 28 82
> [image: Mobile:] +33 (0)6 04 09 74 19
> [image: Skype:] martin.noblecourt
>
> Humanitarian mapping and information management
>
> [image: Website:] cartong.org | [image: Twitter:] @assocCartONG
>  | [image: Address:] Chambéry, France
>
> Lon: 05°55'24'' | Lat: 45°30'20''
> [image: GeOnG 2016 - The Humanitarian Forum for Geographic Information -
> 17th-18th-19th of October - Chambéry, 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] Fwd: confirm 10ff24cf8895bd60980b14b1a6380c7cd66ce656

2016-11-14 Thread François Lacombe

+1 même problème que vous

Impossible de savoir si je suis passé à côté de mails entre temps

A+

*François Lacombe*

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

Le 14 novembre 2016 à 10:19, Erik Amzallag <amzallag.e...@gmail.com> a
écrit :

> Bonjour
>
> Même chose ici.
> J'ai l'impression que Gmail (et d'autres fournisseurs) cause quelques
> problèmes de rebonds depuis quelques jours. J'ai eu le même soucis sur
> d'autres listes que j'administre.
>
> Côté Mailman, il faudrait changer quelques paramétrages dans le traitement
> des rejets, notamment augmenter la limite du nombre de rebonds successifs
> avant désinscription. Si un gentil admin nous lit ici... ;-)
>
> Erik
>
>
>
>
> Le 14 novembre 2016 à 09:45, Francescu GAROBY <windu...@gmail.com> a
> écrit :
>
>> Bonjour,
>> Oui, j'ai lu le même message (les 26 oct. et 5 nov.). J'ai cru que
>> c'était parce que ma boite mail se mettait à spammer... Mais apparemment
>> non !
>>
>> Francescu
>>
>> Le 14 novembre 2016 à 09:09, Romain MEHUT <romain.me...@gmail.com> a
>> écrit :
>>
>>> Bonjour,
>>>
>>> Certains d'entre vous ont-ils reçu un message que celui ci-dessous ?
>>>
>>> Dans mon cas, c'est la 3ème fois en peu de temps. J'ai écrit à
>>> talk-fr-ow...@openstreetmap.org pour connaitre la raison de cet envoi
>>> mais je n'ai pas eu de réponse.
>>>
>>> Une idée ?
>>>
>>> Merci.
>>>
>>> Romain
>>>
>>> -- Message transféré --
>>> De : <talk-fr-requ...@openstreetmap.org>
>>> Date : 12 novembre 2016 à 10:00
>>> Objet : confirm 10ff24cf8895bd60980b14b1a6380c7cd66ce656
>>> À : romain.me...@gmail.com
>>>
>>> Votre abonnement à la liste Talk-fr a été désactivé suite à due
>>> to excessive bounces The last bounce received from you was dated
>>> 05-Nov-2016. Vous ne recevrez plus de messages en provenance de cette
>>> liste tant que vous n'aurez pas ré-activé votre abonnement. Vous
>>> recevrez encore 2 rappels comme celui-ci avant que votre abonnement ne
>>> soit supprimé.
>>>
>>> Pour ré-activer votre abonnement, vous pouvez répondre simplement à
>>> ce message (en laissant la ligne Subject: --Objet-- du message intact)
>>> ou vous rendre à la page de confirmation à l'adresse :
>>>
>>>  https://lists.openstreetmap.org/confirm/talk-fr/10ff24cf889
>>> 5bd60980b14b1a6380c7cd66ce656
>>>
>>> (...)
>>>
>>> Si vous avez des questions ou des problèmes, contacter le
>>> propriétaire de la liste  à l'adresse
>>>
>>> talk-fr-ow...@openstreetmap.org
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>> --
>> Francescu
>>
>> ___
>> 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] Salon Pollutec

2016-11-28 Thread François Lacombe

Bonjour à tous,

Cette semaine se tient le salon Pollutec, grand rendez-vous de certains
acteurs investis dans la gestion des ressources et de l'environnement.

Essayons une petite recherche :
http://www.pollutec.com/Visiter/Les-Exposants-2016.htm?SType=CRITERIA=words_openstreetmap_=Box

C'est pas encore foufou, est-ce que l'asso souhaite investir dans ce genre
d'actions de visibilité ?
Parce que, en attendant Suez et les autres ils continuent à publier des
cartes de bennes à ordure sur Google Maps.

Avec tous les contacts qu'on peut avoir ici avec la métropole lyonnaise, je
devrais bien arriver à faire quelque chose pour un stand l'année prochaine.

A+

François


*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] (sans objet)

2016-11-04 Thread François Lacombe

Bonjour Jérôme,

Je ne vois pas les messages précédents dans ce fil, j’imagine qu'il y en a
d'autres.

Tout est question d'espace de nom, et de collision des noms dans ces
espaces.
Le FR dans ref: permet de distinguer les clés entre des noms qu'on peut
retrouver dans d'autres pays/régions du monde. Et si le référentiel n'est
utilisé qu'en France, alors on donne une information supplémentaire dans le
nom de la clé.

Pour les noms de villes, joker.
name=FR:Paris n'est vraiment pas sexy, pourtant d'un point de vue
sémantique ça se comprend.
L'espace de nommage des villes ou des réseaux de bus est-il national ou
international ?

François

*François Lacombe*

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

Le 4 novembre 2016 à 03:43, Jérôme Amagat <jerome.ama...@gmail.com> a écrit
:

> là il n'y a pas de problème de chevauchement de réseau, il y a un seul
> réseau STAR autour de rennes et même en France. Si on veux les éléments de
> ce réseau on se restreint à une région dans ses recherches pour ne pas
> avoir des éléments d'un hypothétique réseau STAR ailleurs.
>
> Si on met network=FR:STAR alors si on va par là moi je veux que la capital
> de la France est  name=FR:Paris plutôt que name=Paris vu que d'autres
> villes dans le monde s'appellent Paris. :-)
>
> L'histoire dans le wiki du FR: dans le network c'est pour les routes des
> réseaux routiers nationaux ou régionaux qui n'ont pas vraiment de nom
> spécifique.
> Pour ne pas mettre network=Route Départementale de l'Ain (ou quelque chose
> dans le genre) il faudrait mettre network=FR:01:D-road d’après le wiki.
>
> Pour les ref c'est un peu différent et pour moi cela est du au faite qu'il
> peut y avoir plusieurs ref de différentes sortent sur un même objet (comme
> les ref:INSEE et ref:SIREN que l'on a sur des communes par exemple).
>
> ___
> 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 interrupteurs électriques : vote en cours

2016-12-10 Thread François Lacombe

Bonjour à tous,

Je n'avais pas diffusé l'info directement ici il y a 15 jours, le vote de
la proposition que j'ai rédigé sur le wiki pour la cartographie des
"interrupteurs" électriques est en cours.
Cette carto, très industrielle et technique, permet de mieux comprendre le
fonctionnement des réseaux électriques et des flux d'énergie, a l'image de
ce qui est fait sur les voies ferrées.

https://wiki.openstreetmap.org/wiki/Proposed_features/Power_switching_extension

C'est certes en anglais, voici un condense du contenu :
on utilise déjà power=switch pour indiquer un dispositif d'aiguillage de
l'électricité
La nouvelle clé switch=* vient en préciser 4 grandes fonctions
(indépendamment de la forme, couleur ou matériaux)
switch=disconnector, simple sectionneur
switch=mechanical, interrupteur permettant d'ouvrir un circuit en charge
(comme a la maison)
switch=circuit_breaker, disjoncteur pouvant couper même les court-circuita
switch=earthing, sectionneur de mise a la terre

Je vous laisse vous référer aux photos pour avoir des exemples.

Merci par avance pour vos réactions en bas de document si vous en avez

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

Re: [OSM-talk-fr] Proposition interrupteurs électriques : vote en cours

2016-12-10 Thread François Lacombe

Bonsoir Stéphane,

Le 10 décembre 2016 à 20:04, Stéphane Péneau  a
écrit

>
> Heu... la réflexion ne concerne effectivement que l'énergie.
> Comme il a été mentionné, le power:switch aurait eu l'avantage d'être
> cohérent avec railway:switch
>
La proposition ne concerne que l'énergie, mais quitte à introduire une clé,
autant la penser pour servir dans d'autres domaines.
En étant suffisamment générique sur substation=* on a pu l'utiliser avec
les pipelines et sur le railway aussi.
C'est le cas sur location:transition aussi, qui a remplacé au moins 5
clés/valeurs différentes très spécifiques et peu parlantes.

Difficile d’être cohérent avec beaucoup de choses dans le domaine power et
avec railway:switch :(



> Ceci dit, oui, c'est plus cohérent avec les autres clés utilisées, bien
> que l'empilement de clés sur un même point commence à être un peu compliqué
> : on peut se retrouver avec le poteau, le transfo, le switch, les lignes de
> différentes tensions,  tout cela sur un seul et même point, alors que ce
> sont des éléments différents. On retrouve un peu ce genre de problématique
> en mapping indoor.
>
Dans le cas de différents éléments uniques, justement l'assemblage de
plusieurs clés sert parfaitement, sans redonder le contexte.
power=pole
switch=mechanical
transformer=distribution

On a aussi le même problème avec plein d'antennes sur un même poteau.

Ce peut alors être l'occasion de créer des nœuds distincts.


> Pour ma part, si j'ajoute des switches, je risque d'être bien en peine
> pour savoir de quel type il est. Ça risque de se terminer en switch=yes
>
Ca n'est pas un problème.
Ca laisse l'occasion à quelqu'un de plus qualifié de venir compléter l'info
après coup.

Chaque goutte rempli l'océan, et la démarche de documenter correctement de
nouvelles clés et démarches est très fastidieux.
Il y a un gros taff sur telecom=*

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

Re: [OSM-talk-fr] Proposition interrupteurs électriques : vote en cours

2016-12-10 Thread François Lacombe

Suite aux différentes réactions déjà reçues ce jour, peut être est
l'occasion d'apporter la précision suivante sur cette propal.

Le parti est pris d'introduire une clé suffisamment générique, switch=*,
pour servir dans d'autres domaines, avec d'autres valeurs.
power:switch= est moins opportun, parce que la réflexion n'aurait concerné
que le domaine de l'énergie.
Il n'existe pas, par ailleurs, de power:location, power:substation ou
power:plant.

En utilisant ces clés sur des objets qualifiés avec power=* le contexte est
connu de facto et il serait redondant de l'indiquer une deuxième fois.

Des doutes sur la capacité a dissocier une "sous-station" électrique du
reste ?
Pas de soucis sur overpass : ["power"]["substation"]
Idem avec les interrupteurs : ["power"]["switch"]

La liste des valeurs est suffisamment précise pour faire une QA efficace.

By the way, merci pour vos retours.

François

Le 10 déc. 2016 2:01 PM, "François Lacombe" <fl.infosrese...@gmail.com> a
écrit :

Bonjour à tous,

Je n'avais pas diffusé l'info directement ici il y a 15 jours, le vote de
la proposition que j'ai rédigé sur le wiki pour la cartographie des
"interrupteurs" électriques est en cours.
Cette carto, très industrielle et technique, permet de mieux comprendre le
fonctionnement des réseaux électriques et des flux d'énergie, a l'image de
ce qui est fait sur les voies ferrées.

https://wiki.openstreetmap.org/wiki/Proposed_features/
Power_switching_extension

C'est certes en anglais, voici un condense du contenu :
on utilise déjà power=switch pour indiquer un dispositif d'aiguillage de
l'électricité
La nouvelle clé switch=* vient en préciser 4 grandes fonctions
(indépendamment de la forme, couleur ou matériaux)
switch=disconnector, simple sectionneur
switch=mechanical, interrupteur permettant d'ouvrir un circuit en charge
(comme a la maison)
switch=circuit_breaker, disjoncteur pouvant couper même les court-circuita
switch=earthing, sectionneur de mise a la terre

Je vous laisse vous référer aux photos pour avoir des exemples.

Merci par avance pour vos réactions en bas de document si vous en avez

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

Re: [OSM-talk-fr] Salon Pollutec

2016-12-06 Thread François Lacombe

Bonsoir Christian,

Merci pour ton message (désolé du temps mis à la réponse, gmail qui colle
laposte.net en spam encore).

Je donnais l'exemple de pollutec parce qu'il m'est venu en tête.
Aucune idée cependant des contraintes pour disposer d'un stand à ce genre
de salon.
C'est valable aussi pour le salon des maires et bien d'autre.

C'est à murir collectivement ici avant toute chose


Bonne soirée

*François Lacombe*

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

Le 28 novembre 2016 à 11:10, <g...@laposte.net> a écrit :

> Salut François
>
> de tout coeur avec toi sur le sujet, d'ou la question complementaire à ta
> proposition de sensibiliser la Métropole :
> - Que doit-t'on/peut-t'on faire pour t'aider dans ta demarche ?
> Nota: Sylvain avait fait une carte des exposants du salon Primevere,
> est-ce une base de départ !
>
> A+
> Christian - gnrc
>
> ------
> *De: *"François Lacombe" <fl.infosrese...@gmail.com>
> *À: *"Discussions sur OSM en français" <talk-fr@openstreetmap.org>
> *Envoyé: *Lundi 28 Novembre 2016 09:41:55
> *Objet: * [OSM-talk-fr] Salon Pollutec
>
> Bonjour à tous,
>
> Cette semaine se tient le salon Pollutec, grand rendez-vous de certains
> acteurs investis dans la gestion des ressources et de l'environnement.
>
> Essayons une petite recherche :
> http://www.pollutec.com/Visiter/Les-Exposants-2016.
> htm?SType=CRITERIA=words_openstreetmap_=Box
>
> C'est pas encore foufou, est-ce que l'asso souhaite investir dans ce genre
> d'actions de visibilité ?
> Parce que, en attendant Suez et les autres ils continuent à publier des
> cartes de bennes à ordure sur Google Maps.
>
> Avec tous les contacts qu'on peut avoir ici avec la métropole lyonnaise,
> je devrais bien arriver à faire quelque chose pour un stand l'année
> prochaine.
>
> A+
>
> François
>
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux <http://www.twitter.com/InfosReseaux>
>
> ___
> 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] Isolation du bâti sur OSM et efficacité énergétique, ce que vous allez découvrir va vous étonner

2016-12-06 Thread François Lacombe

Bonsoir à tous,

Une idée est revenue plusieurs fois dans différentes discussions sur ce que
nous faisons sur les réseaux de transport d'énergie : l'isolation des
lignes/câbles.
De fil en aiguille, on pense également à l'isolation thermique de certains
pipelines
Et enfin on en vient à rêver d'avoir les infos sur l'isolation thermique du
bâti.

Une proposition va être écrite en ce sens sur le wiki
https://wiki.openstreetmap.org/wiki/Proposed_features/Insulation_proposal

On nous parle de plus en plus de rénovation de l'habitat, d'efficacité
énergétique. Donnons les moyens à OSM de rassembler de l'information
factuelle à ce propos.

Peut-être avez-vous déjà des idées, commencé à réfléchir ?

Le sujet est vaste, il existe beaucoup de technique/matériaux. Progressons
par étapes.
Techniquement, on utiliserait la clé insulation=* pour classifier dans les
grandes lignes l'isolation en présence (peut-être carrément le type
thermique, électrique, acoustique, étanchéité,...).
Ensuite on pourra exploiter le namespace insulation:* pour donner plus
d'infos.
Ça reste à définir.


Nul doute que ce peut être génial.

A+

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

[OSM-talk-fr] La Force... en français sur le wiki

2017-01-09 Thread François Lacombe

Bonsoir à tous

Bonne année 2017 pour ceux à qui je n'ai pas encore eu l'occasion de la
souhaiter :)

Je tenais à donner quelques liens pour bien démarrer :
Les pages du wiki récemment améliorées puis votées en anglais dans la
catégorie power sont dispo en français (les interrupteurs et leurs
fonctions)
https://wiki.openstreetmap.org/wiki/FR:Tag:power%3Dswitch
https://wiki.openstreetmap.org/wiki/FR:Key:switch
et ainsi de suite...

Il reste à faire sur les transformateurs et l'isolation du bâti
Voir ici : https://wiki.openstreetmap.org/wiki/User:Fanfouer

Il y a également deux projets qui viennent accompagner NewCloudAtlas de Tim
Waters :
OpenInfraMap (de @ruusss, @iio...)
https://openinframap.org/#lat=46.339=3.713=7
Une mise en valeur des domaines Power, telecoms, Pipeline et autres...
Plus d'infos sur le GitHub https://github.com/openinframap/

OpenGridMap
http://opengridmap.com/
Un projet de l'université de Munich qui vise à carto tout se qui se
rapporte à l'énergie
Pas de liens (encore) avec OSM si ce n'est le fond de carte, les choses
devraient évoluer prochainement


A+

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

Re: [OSM-talk-fr] fiber=yes ?

2016-12-18 Thread François Lacombe

Bonjour Mael,

Le 17 décembre 2016 à 14:30, Maël REBOUX  a
écrit :

> Bonjour,
>
> Ce matin je tombe dans la rue sur une armoire telecom flambante neuve
> installée dans la semaine.
> Elle servira au FTTH car le déploiement fibre est en cours dans ma ville.
> https://twitter.com/mael_reboux_bzh/status/810061582231289857
>

+1


> *Je militerais bien pour le simple tag fiber=yes car, en l’occurrence il
> est certain que cette armoire est dédiée à la fibre et que ce serait
> dommage de l’oublier.*
>


Pourquoi pas
Une proposition est toujours en draft sur ce sujet :
https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_local_loop

On pensait à telecom:medium=fiber... voire medium=fiber directement.
Comme dit en 2014, ca n'est pas un caractère de l'armoire mais la
description du réseau qui passe à l'intérieur : plusieurs réseaux
s'appuyant sur des medium différents peuvent passer.
C'est le cas dans les armoires Numéricâble où est faite la transition
coax/fibre.
On devrait trouver soit fiber=yes + coax=yes ou bien
telecom:medium=fiber;coax

Jsuis ni fan des listes à ; ni des clés avec pour seule valeur yes
Dilemme :/

Bonne fin de weekend

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

Re: [OSM-talk-fr] fiber=yes ?

2016-12-21 Thread François Lacombe

Bonjour Jean-Yvon,

Le 18 décembre 2016 à 20:49,  a écrit :

> Je vais te proposer de mettre fin à ton dilemme :
> telecom:medium:fiber=yes
> telecom:medium:coax=yes
>
> Pas de soucis pour les armoires à usage multiple.
> Et comme il y a trois et non deux cas (yes, no, absence de tag)
>

En fait le dilemme se situait entre les listes à ; :
telecom:medium=fiber;coax et les tag "yes" : telecom:medium:fiber=yes +
telecom:medium:coax=yes
J'avais d'ailleurs reproché ça à une proposition d'extension du modèle des
écoles/universités en début d'année où trop de clés avec pour seule valeur
yes étaient utilisées.

Vu qu'il n'y a pas de solution parfaite, à mon avis les clés =yes sont
meilleures que des listes difficiles à manipuler.


> Tu veux dire : du réseau à l'armoire en fibre et de l'armoire à l'abonné
> en coax, pas que l'armoire gère des réseaux basés sur deux technologies
> différentes.
>
C'est ça, mais si l'armoire se situe à la connexion entre la fibre qui
arrive du "central" (le cmts) et le coax qui dessert les abonnés, il y a
bien deux medium différents à l'intérieur.



> Intéressant mais je ne vois pas ça dans le schéma. Non, je ne propose pas
> d'ajouter cette information mais je suis prêt à te l'entendre dire.
> Ce serait par exemple :
> telecom:service_level:FTTH pour l'armoire fibre et FTTLa pour l'armoire
> fibre/coax.
> Comme ça on n'aurait pas de valeurs multiples ? Je dis peut-être une
> connerie, ne pas hésiter à le dire, j'aurais encore appris qqc ce soir.
> Par exemple, est-ce quelque chose distingue le FTTH (H=Home, prise
> individuelle) et le FTTB (B=building, fibre à l'immeuble, autre techno
> ensuite) d'une point de vue réseau ? Est que le  FTTB n'est pas un FTTH
> suivi d'un FTTLa  (ou plutôt FTTC) dans l'immeuble ?
> http://www.ariase.com/fr/guides/fibre-optique.html
>

Intéressante cette clé telecom:service_level
En France ça peut marcher, parce qu'il n'y a pas de cas où les boucles
locales sont mélangées, certains font du FTTH, d'autres FTTLa et c'est
étanche
Par contre je crois savoir que dans d'autres pays d'Europe du nord, il
mélangent les deux dans les mêmes armoires, on va avoir le même problème
que fibre/coax.

Il est certain qu'un FTTB s'accompagne d'une techno quelconque pour rallier
l'abonné en bout de réseau (peut-être du coax via DocSis ou même du VDSL).

On ne souhaitais pas descendre à ce niveau de détail là pour l'instant
La solution avec telecom:medium:fiber=yes est la plus polyvalente.
Peut-on se risquer à utiliser medium:fiber=yes, sans telecom: ?


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

Re: [OSM-talk-fr] Sortie de MapContrib 1.6

2017-03-18 Thread François Lacombe

Bonsoir Guillaume,

Merci pour les infos et le travail jusque là

Très sympa cette évocation d'une intégration Osmose, impatient de tester ca
;)

A+

François

*François Lacombe*

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

Le 17 mars 2017 à 20:07, Guillaume AMAT <guilla...@amat.io> a écrit :

> Salut !
>
> MapContrib est de sortie pour sa nouvelle version mensuelle. Pas de gros
> changements mais on aime bien livrer les nouveautés assez tôt et
> régulièrement.
>
> Dans les grandes lignes, MapContrib a maintenant 4 fonds de carte activés
> par défaut (OSM, OSM monochrome, Watercolor et Mapbox satellite) et un
> bouton « Afficher plus de fonds » juste en-dessous, le créateur de thème
> peut forcer la valeur d'un tag via les presets et quelques colonnes ont
> maintenant un bouton retour pour faciliter la navigation dans l'interface.
>
> Vous trouverez plus de détails dans l'article dédié sur le blog :
> https://blog.mapcontrib.xyz/fr/2017/03/mapcontrib-1-6
>
> Guillaume
>
> ___
> 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] Suppression du tag ISO3166-1 sur la relation France Métrpolitaine

2017-03-18 Thread François Lacombe

Bonsoir,

Tout est dans le titre, dans un changeset datant d'il y a 5 jours, la
relation "France métropolitaine" a perdu son tag ISO3166-1=FX.
https://www.openstreetmap.org/relation/1403916

Résultat mes requêtes Overpass sont par terre, parce que je m'en servais
pour constituer une area.

Il y a eu une décision provoquant ce changement à côté de laquelle je serai
passé ?
Sinon je suis pour un revert, parce que ca me semble très structurant.

Sur la relation France, on voit apparaitre ISO3166-1:numeric,
ISO3166-1:alpha2...
https://www.openstreetmap.org/relation/2202162

Merci par avance

François

--
*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données RTE...

2017-03-14 Thread François Lacombe

Hello

Super effort de leur part, évidemment tres interessant de mon point de vue
:)

Pour les pylônes, il ont du dupliquer les supports qui prennent part à
plusieurs lignes (6 cables = 2 lignes).
Parce que ces supports n'ont pas de reference nationale, ils sont
identifiés par un numero et la ligne à laquelle ils prennent part donc
peuvent virtuellement exister autant de fois que de lignes supportées (cf
le terrain).

Simple supposition, je n'ai pas tout regardé

Une integration via osmose est-elle envisageable ?
Depuis le temps que je souhaiterais me plonger dans les tests deja existant
dans le domaine

François

Le 14 mars 2017 20:12, "mides.map"  a écrit :

> Effectivement belle ouverture de données.
>
> Par contre, j'ai dû sauter quelques lignes dans les explications pour les
> données concernant les pylônes RTE , https://www.data.gouv.fr/fr/da
> tasets/pylones-rte/ , 265271 points au format GeoJSON et 5 au format
> Shape. De même concernant l'info  Lambert 93 alors que l'on est en WGS84.
>
> Michel
>
> Le 14/03/2017 18:23, Nicolas Moyroud a écrit :
>
>> Ah oui pas mal en effet ! La hauteur et le numéro des pylônes c'est
>> intéressant pour compléter ceux que j'avais déjà fait sur mon secteur :-)
>>
>> Nicolas
>>
>> Le 14/03/2017 à 17:15, Christian Quest a écrit :
>>
>>> Beau lâché de données opendata par RTE ce matin sur
>>> https://www.data.gouv.fr/fr/organizations/reseau-de-transpor
>>> t-delectricite/
>>>
>>> Lignes aériennes (de 45kV à 400kV), souterraines, pylones, postes
>>> électriques...
>>>
>>>
>>> Un beau chantier d'intégration en perspective !
>>>
>>>
>>>
>>
>> ___
>> 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] Suppression du tag ISO3166-1 sur la relation France Métropolitaine

2017-03-20 Thread François Lacombe

Merci pour ces retours,

J'ignorais que ce code avait été retiré de l'ISO.
Du coup, hormis l'identifiant wikidata, aucun moyen d'identifier de manière
certaine la relation ? (rechercher name=France c'est pas tellement de
l'identification)



*François Lacombe*

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

Le 19 mars 2017 à 16:09, <osm.sanspourr...@spamgourmet.com> a écrit :

> Effectivement mon clavier a fourché ;-).
>
> FR c'est sur l'autre relation et sans information temporelle.
>
> Le 19/03/2017 à 15:58, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Euh non, justement pas FR mais FX. Le code FR déjà désignait la France
> entière en 1993-1997, en plus de FX pour la métropole seule (territoire
> européen: continent+Corse et îles côtières).
>
>
>
> Le 19 mars 2017 à 13:50, <osm.sanspourr...@spamgourmet.com> a écrit :
>
>> Ça fait 20 ans que ce code n'est plus ISO : Newsletter I-2
>> <http://www.iso.org/iso/iso_3166-3_newsletter_i-2.pdf>
>>
>> Donc ISO3166-1:1993-1997 (alors que c'est la mise à jour de 2002 qui
>> ajoute cette entrée dans la norme de 1999 qui initialement avait oublié de
>> noter cette entrée... comme supprimée).
>>
>> Ou pour être homogène :
>> ISO3166-1:numeric:1993-1997=249
>> ISO3166-1:alpha2:1993-1997=FR.
>>
>> Ça me semble utile : ça ne mange pas de pain et évitera que qu'autres se
>> posent la question.
>>
>>
>>
>> Le 19/03/2017 à 01:27, Philippe Verdy - verd...@wanadoo.fr a écrit :
>>
>> Je pense que celui qui a supprimé ce code a pensé qu'il n'était pas
>> nécessaire, croytnat que FR est suffisant alors que ça inclue toute la
>> France y compris les outre-mer qui ont (pour certains mais pas tous) leur
>> propre code ISO 3166-1.
>> Quitte à remettre un code ISO (si l'identifiant Wikidata ne te semble pas
>> plus stable que les codes ISO), autant que ce soit sur un tag différent,
>> ISO3166-1 avec un suffixe de date mentionnant l'année où le code était
>> encore standard.
>>
>>
>> Le 19 mars 2017 à 00:56, Philippe Verdy <verd...@wanadoo.fr> a écrit :
>>
>>> C'est vrai qu'il n'y avait aucune obligation à le faire (même si le code
>>> a été rendu obsolète dans I'ISO, il reste inutilisé pour autre chose pour
>>> l'instant)
>>> Sinon tu peux toujours utiliser la recherche par nom, ou par
>>> wikidata=Q212429 qui garde un identifiant stable
>>>
>>>
>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>>  Garanti
>>> sans virus. www.avast.com
>>> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>>>
>>> Le 19 mars 2017 à 00:06, François Lacombe <fl.infosrese...@gmail.com> a
>>> écrit :
>>>
>>>> Bonsoir,
>>>>
>>>> Tout est dans le titre, dans un changeset datant d'il y a 5 jours, la
>>>> relation "France métropolitaine" a perdu son tag ISO3166-1=FX.
>>>> https://www.openstreetmap.org/relation/1403916
>>>>
>>>> Résultat mes requêtes Overpass sont par terre, parce que je m'en
>>>> servais pour constituer une area.
>>>>
>>>> Il y a eu une décision provoquant ce changement à côté de laquelle je
>>>> serai passé ?
>>>> Sinon je suis pour un revert, parce que ca me semble très structurant.
>>>>
>>>> Sur la relation France, on voit apparaitre ISO3166-1:numeric,
>>>> ISO3166-1:alpha2...
>>>> https://www.openstreetmap.org/relation/2202162
>>>>
>>>> Merci par avance
>>>>
>>>> François
>>>>
>>>> --
>>>> *François Lacombe*
>>>>
>>>> fl dot infosreseaux At gmail dot com
>>>> www.infos-reseaux.com
>>>> @InfosReseaux <http://www.twitter.com/InfosReseaux>
>>>>
>>>> ___
>>>> 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
>>
>> ___ Talk-fr mailing list
>> Talk-fr@openstreetmap.org https://lists.openstreetmap.or
>> g/listinfo/talk-fr
>
> ___
> 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

Re: [OSM-talk-fr] Données RTE...

2017-03-14 Thread François Lacombe

Le 14 mars 2017 à 22:58, Christian Quest  a écrit :

> Cette limite à 5 objets dans les shapefile provient des outils
> d'OpenDataSoft... c'est un défaut qui a toujours existé malheureusement et
> n'a jamais été corrigé.
>
> Donc prendre le geojson... et là on a tout de jeu de données.
>

Well, autant pour moi, le problème de duplication des supports s'était posé
par le passé, mais ca n'est pas le cas ici, c'est vérifié.

Il existe une clé pour les champs de codifs pour les postes et lignes :
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:RTE_nom
Peu de valeurs sont dispo sur OSM et le rapprochement va largement aider à
la compléter

Exemple ici sur un poste (périmètre)
https://www.openstreetmap.org/way/199229562

Et sur une relation circuit
https://www.openstreetmap.org/relation/5459750#map=11/45.9756/6.0490

Attention, les identifiant (codif 1 de la ligne, codif 2 de la ligne) ne
sont pas les identifiants des files de pylônes (ways sur OSM) mais des
circuits logiques supportés (relations dans OSM avec les ways power=line
pour membres)
Il ne faut pas reporter ces valeurs sur les ways en elles-même mais bien
sur des relations les ayant pour membre, comme ci-dessus.
https://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/France#Circuits_et_routage_sur_le_r.C3.A9seau


Il y a une requete overpass pour obtenir les circuits connus en 400kV et
225kV
http://overpass-turbo.eu/s/k19


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

Re: [OSM-talk-fr] OpenData RTE dans Osmose-QA

2017-04-23 Thread François Lacombe

Hello,

Côté power, pas en faveur du tout d'indiquer les pylônes avec un polygone
marquant l'aire de la base.
C'est parfois fait en sortie du cadastre et indiqué en building=yes wall=no
mais je le supprime systématiquement.
Si tant est qu'il faille l'évoquer, un polygone est assez complexe à
intégrer à une ligne (en l’occurrence les câbles supportés par le pylône).

Pour les références, chez RTE le numéro d'un pylône n'est pas unique
nationalement. Utiliser ref:FR:RTE ne me semble pas judicieux.
En revanche on pourrait créer un ref:FR:RTE_support documenté correctement
en indiquant que c'est une référence unique sur la file de pylône sur
laquelle il prend effet.
Ainsi les points géodésiques IGN n'entreront pas en conflit et on pourra
continuer d'utiliser un simple noeud pour tout le monde.


A+


*François Lacombe*

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

Le 23 avril 2017 à 11:03, Art Penteur <art.pent...@gmail.com> a écrit :

> C'est l'occasion de poser la question du codage des pylônes qui
> portent un point géodésique.
>
> Exemple : http://www.openstreetmap.org/node/670155064#map=17/44.
> 41231/1.41735
>
> Quelle solution fait consensus, actuellement ?
>   - 1 seul nœud avec tous les attributs (power-=tower et  man_made
> survey_point). ça a une certaine cohérence physique, mais pose des
> problèmes de codage (par exemple, comment combiner la ref IGN et la
> ref RTE) ?
>   - 2 nœuds très proches (éventuellement liés par une relation de type
> site)
>   - créer un polygone power=tower, avec un nœud à chacun des pieds du
> pylône, avec le survey_point naturellement à l'intérieur du polygone
> (mais la page wiki de power=tower interdit les polygones) ?
>   - autre ?
>
> Art
>
> Le 22 avril 2017 à 11:50, David Crochet <david.croc...@free.fr> a écrit :
> > Bonjour
> >
> >
> > Le 22/04/2017 à 11:43, Frédéric Rodrigo a écrit :
> >>
> >> d'autant plus que les positions RTE sont généralement bonne.
> >
> >
> > Oui, en zoommant bien, la donnée RTE est plus précise que le
> positionnement
> > manuel.
> >
> > Cordialement
> >
> > --
> > David Crochet
> >
> >
> >
> > ___
> > 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] Problème pour taguer un poste de gaz

2017-08-02 Thread François Lacombe

Hello,

pipeline=substation est bien la bonne piste, normalisée il y a 1 ou 2 ans
pour suivre ce qui avait été fait pour les réseaux électriques.
https://wiki.openstreetmap.org/wiki/Tag:pipeline%3Dsubstation

Par contre il ne faut pas mettre man_made=pipeline dessus.

Il y a une clé substation=* à mettre pour donner la fonction du poste.
Je serai prenneur de la photo de la plaque indicative jaune sur la grille
pour aider à en déterminer la valeur.
=> Logique à indiquer sur une traduction française de la page


Bonne soirée

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

Re: [OSM-talk-fr] Point d'eau potable hors service

2017-08-17 Thread François Lacombe

Hello,

OSM est-il bien l'outil adapté pour relever la présence d'éléments hors
service sur le terrain ?
Serons-nous en mesure d'indiquer le changement d'état dans les temps ?

Relever la présence d'un équipement fonctionnel ou non, ok
Par contre, pour prévenir d'un dysfonctionnement, c'est plus du role
d'applications comme CityLity ou autres.

D'un point de vue sémantique, j'aime bien operational_status=out_of_order


A+

*François Lacombe*

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

Le 17 août 2017 à 10:55, JB <jb...@mailoo.org> a écrit :

> S'il n'y a pas d'eau qui coule, je ne le note pas avec
> amenity=drinking_water (ben non, il n'y a pas d'eau). Ceux qui cherchent un
> point d'eau ne filtreront pas les tags supplémentaires, donc l'information
> qu'il est cassé doit être dans le tag principal.
> disused:amenity=drinking_water avec un note ou description=* est le plus
> adapté.
> JB.
>
> Le 16/08/2017 à 06:45, Jean-Christophe Becquet a écrit :
>
>> Bonjour,
>>
>> J'ai contribué un point d'eau potable avec le greffon Contribuer à OSM
>> d'Osmand~ :
>> https://www.openstreetmap.org/node/5037241738
>> amenity=drinking_water
>>
>>
>> Quel est le meilleur moyen d'indiquer que le robinet ne fonctionne pas ?
>>
>> disused=yes
>> http://wiki.openstreetmap.org/wiki/FR:Tag:disused%3Dyes
>>
>> stateofrepair=needs_repair
>> comme proposé sur
>> http://wiki.openstreetmap.org/wiki/Proposed_features/Drinkin
>> g_water_attributes
>>
>> operational_status=out_of_order
>> https://taginfo.openstreetmap.org/tags/operational_status=out_of_order
>>
>> L'idée ensuite : une requête Overpass qui viendrait alimenter une carte
>> Umap à destination des services techniques de la ville ?
>>
>> De toutes façons, il me semble utile de prévenir les éventuels usagers
>> de la base OSM que le point d'eau est HS.
>>
>> Merci
>>
>> Bonne journée
>>
>> JC
>>
>
>
> ___
> 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] Osmose : cours d'eau qui se jette dans un lac

2017-07-09 Thread François Lacombe

Bonjour

Peut etre est ce déjà le cas, mais même si une riviere est un affluent d'un
lac, il doit y avoir un reseau topologique de waterway dans le lac pour
informer sur les differents écoulements.

Ici, le lac a bien un derversoir et donc les affluents devraient y etre
connectés via un waterway=river
Ce qui ferait disparaître ainsi le signalement osmose

Partagez-vous ce point de vue ?

François

Le 9 juil. 2017 14:54, "lenny.libre"  a écrit :



Le 09/07/2017 à 11:42, Philippe Verdy a écrit :

oui mais le lac en général est la "riverbank" d'un autre cours d'eau qui le
traverse. Ton petit cours d'eau peut se connecter à cet autre cour, au
milieu du lac.

Ici il s'agit d'un étang cotier, mais il doit bien y avoir un petit cours
d'eau qui le relie à la mer (pas beaucoup plus gros que le cours que tu as
relié à l'étang... peut-être le même ? Je pense que c'est le cours vers le
sud (utilisé par le canal transaquitain qui passe par la zone de marais et
plusieurs autres étangs) puis qui se jette en mer vers l'ouest (par le
courant de Mimizan)

J'aurais du regarder plus loin que le bout de mon nez quand je me suis
assis au bord du lac. (Je n'avais pas vu le canal, mais je l'avais croisé
en passant sur le petit pont)
Je ne pense pas qu'il aille jusqu'à Mimizan au sud du Bassin d'Arcachon,
alors que nous sommes au Nord du Bassin, par contre dans osm, le canal se
termine sur un point au milieu du Bassin et non sur la côte ...


Le 9 juillet 2017 à 10:53, lenny.libre  a écrit :

> Bonjour
>
> J'ai un signalement sur un cours d'eau qui se jette dans un lac
>
> *Cours d'eau non connecté ou sens d'écoulement incorrect*
> *way 313224664 *
> rawedit  josm
> 
> edit 
> *name* = Craste de Gaillin
> *source* = cadastre-dgi-fr source : Direction Générale des Impôts -
> Cadastre. Mise à jour : 2013
> *waterway* = stream
>
> Il se jette dans l'Étang de Cazaux-Sanguinet
> http://www.openstreetmap.org/way/25050617#map=12/44.4701/-1.1773
>
> *Attributs*
> *name Étang de Cazaux-Sanguinet*
> *natural water*
> *water lake*
>
> Je pense que ce cas (un cours d'eau que ne se jette pas dans la mer, mais
> dans un étang ou un lac) n'est pas unique ; y a-t-il des tags à ajouter au
> cours d'eau ou à l'étang pour ne pas créer de signalement ?
>
> merci d'avance
>
> Leni
>
> ___
> 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



___
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] Test panneaux de signalisation Osmose-Mapillary

2017-07-17 Thread François Lacombe

Hello,

C'est une super initiative Frédéric
Comme tu le soulignes, il faut encore que les positions des panneaux soient
consolidées avec les différentes prises de vues.
Mapillary m'a dit qu'ils travaillent dessus. Ce n'est qu'une question de
patience


Le 16 juillet 2017 à 23:03, marc marc  a écrit :

> Cela rouvre le débat sur tager le panneau exactement là oü il est (avec
> l'imprécision gps d'autant plus criante) ou tager le panneau en fonction
> de son effet (sur le chemin concerné) afin de le rendre utilisable par
> le routing (le routing ne cherche pas les panneaux situés à proximité)
>

Même sur la ML internationale il n'y a plus trop de doutes : il faut taguer
les deux.
Le panneau en lui-même parce que c'est un objet visible et d'intérêt, ne
serait-ce que pour savoir que l'espace est occupé
Et ensuite l'effet sur les routes/voies concernées, parce qu'on est
difficilement capable de déduire l'effet d'un panneau avec sa simple
position.



> est-ce que les tag source ne gagnerait pas être sur le changeset ?
> c'était un peu l'ancienne méthode de mettre la source de la première
> modif sur l'objet et ensuite elle y reste même quand la modif suivante a
> une autre source
>

+1 sur le changeset


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

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Bonjour Jean-Yvon,


Le 21 juillet 2017 à 09:38,  a écrit :

> Pas complètement d'accord ou je n'ai pas compris ce que tu entends par
> tampon.
>
> Car Jungle Bus est dans l'édition de données.
>
> Si tu ajoute des arrêts mais ne les vois pas, c'est gênant. Déception du
> contributeur (ai-je bien tagué ?) et risque de double contribution.
>
Puisqu'on maitrise le tampon, il faut le mettre à jour au rythme des
éditions.
Ensuite, soit on fait un synchro assez poussée avec l'overpass, ou alors on
le flush carrément en réimportant en prenant pour principe que tout ce qui
est dans la base monde est l'unique vérité toutes les x heures.

C'est aussi ce qui avait été évoqué pour mapcontrib (en ayant le beau rôle
du yakafokon pour ma part)

De toute façons il faut trouver des solutions, toutes les applis ne peuvent
pas reposer que sur les instances publiques de l'overpass
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Bonjour,

Je partage l'avis de Marc sur la mise en place d'un tampon métier.
L'overpass API couvre tellement d'acteurs et de cas d'usages qu'il n'est
pas raisonnable de lui demander d'encaisser 100% de la charge d'un projet
en particulier.

En montant un buffer (pas un cache), vous pouvez mieux maitriser les mises
à jour de vos données, depuis l'overpass mais aussi depuis d'autres sources
selon un fonctionnement qui vous est propre.
Je n'avais pas prêté attention à cette hypothèse de design de Jungle bus

Il en va de même pour tous les projets qui s'appuient directement sur
overpass


A+

*François Lacombe*

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

Le 21 juillet 2017 à 00:23, marc marc <marc_marc_...@hotmail.com> a écrit :

> Bonsoir,
>
> Je suis fan de la haute disponibilité et solution équivalente.
>
> Il y a 2 overpass api planté : allemande et française.
> Une première solution applicative est d'avoir la liste de toute les
> serveurs overpass api et de passer au suivant en cas d'erreur dans un
> ordre statique ou dans un ordre dépendant de la localisation de ce qu'on
> demande.
> Ce choix peux se faire dan l'app ou idéalement il faudrait des "proxy
> d'api" ultra léger qui s'en chargent.
> C'est la structure classique d'une infra HA (reverse proxy redondant
> devant des serveur applicatifs redondant)
>
> Mais l'expérience m'a appris que le plus stable est souvent le cache.
> N'ayant pas pu tester Jungle Bus (incompatibilité), je me demandais que
> pouvait demander l'application de si dynamique ?
> Un arrêt de bus, cela ne bouge pas souvent, une ligne de bus non plus.
> Sauf erreur de ma part, osm a une copie locale de la base mondiale.
> N'est-il pas envisageable d'avoir la votre qui se mettrait à jour avec
> des diffs concernant les quelques types d'objets concernés ?
> J'imagine cela en mode push, sous forme de diff, sur le même modèle que
> osm.fr reçoit lui-même des infos pour garder sa copie locale à jour.
> Le seul hic c'est que les export de diff n'ont peut-être pas encore de
> filtre autre que géographique. Trimble Data a l'air de le faire sur
> requête manuelle, il faudrait l'équivalent en push.
>
> L'autre partie de la solution c'est d'avoir une alerte quand l'api est
> en rade afin d'éviter qu'elle le reste trop longtemps et de pouvoir en
> trouver aussi plus facilement la cause.
> Peut-être que cela existe déjà mais je n'ai rien vu sur la ml tech.
>
> --
>
> Le 20. 07. 17 à 21:07, Florian LAINEZ a écrit :
> > Salut,
> > Aujourd'hui on a eu -encore !- une interruption de service sur
> > l'overpass API. Cela a impacté l'appli Jungle Bus mais j'imagine tout un
> > tas d'autres services qui se basent dessus.
> > J'ai l'impression que cela se produit souvent. Je constate dans mes
> > projets que ce service reste le maillon faible technique et impose de
> > mettre en place une pénible redondance.
> >
> > Est-ce que vous sauriez à quoi cela est dû ? Quelles en sont les causes
> > profondes ?
> > Y aurait-il une solution que nous pourrions mettre en place pour venir
> > en soutien à nos amis les teutons qui gèrent le bouzin ?
> > Est-ce plutôt un besoin de dev ou d’hébergement ?
> > Bref, on résout le problème ? ;)
> ___
> 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] Sécuriser Overpass API : quelles solutions ?

Sur le fond on est d'accord, il va falloir disposer de ressources locales
au projet pour ne plus dépendre d'OAPI.

Par contre, est-ce utile et justifié de monter une instance overpass en
ayant préalablement épuré le jeu de données à ce qui nous intéresse
uniquement ?
Remonter un backend conforme à l'API central pour l'édition, qui
dupliquerait le flux d'édition à la fois dans la base locale et sur OSM
d'une part et qui permettrait de charger ces données dans l'appli frontend
sur une bbox d'autre part ne requiert pas la puissance (et complexité
adjacente) d'overpass.

My 2 cents



*François Lacombe*

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

Le 21 juillet 2017 à 11:26, Christian Quest <cqu...@openstreetmap.fr> a
écrit :

> Le 21/07/2017 à 10:48, marc marc a écrit :
>
> Comment fonctionne un serveur overpass ? il a
> - une copie locale de la base mondiale
> - un moyen pour la garder à jour (par ex chaque minute via un diff)
>
>
> Oui, dans les grandes lignes c'est ça, la particularité c'est que la base
> a une structure propre à overpass et a été spécialement conçue pour
> l'organisation des données OSM. C'est ça qui fait qu'overpass est très
> performant car spécialement conçu pour cet unique usage.
> Il n'y a pas de postgres ou autre utilisé (sauf, il me semble pour les
> "area").
>
> Si Jungle bus avait sa base locale contenant toutes infos couramment
> utilisée par cet app (plateorm, bus_stop, stop_area, route=bus),
> Jungle bus pourrait interroger cette overpass "privé" au lieu d'un
> overpass "public". Cette copie locale serrait très petite en
> taille vu qu'il y a moins de 2 millions de ces 4 tag
> La maj de cette copie serrait très petite aussi vu qu'un arrêt de bus ne
> change pas souvent.
>
>
> Voilà... on ne traite qu'un tout petit sous ensemble des données OSM et ça
> allège du coup beaucoup de choses !
>
> La seule chose qui reste à créer c'est un "diff" non pas mondial ou
> géographique comme cela existe déjà mais sur base d'un nombre limité
> d'objet (par exemple plateorm+bus_stop+stop_area+route=bus)
>
>
> osmfilter / osmconvert ou osmosis peuvent servir à ça en amont pour
> filtrer les diff avant de les injecter dans l'update d'overpass afin de ne
> garder que ce qui est utile.
>
> Quand au délais de maj, il existe sur tous les serveurs.
> si tu interroges l'overpass allemand, il a une minute de décalage.
> La copie local aurait le même genre de lag.
> Cela n’empêche en rien de voir le résultat de ton édition.
> Des app comme Go Map conservent une copie de ce que tu as envoyé
> Le seul effet réel est que si tu as 2 smartphones,
> les modifs de l'un mettront une minute pour être visible sur l'autre.
> C'est le cas pour d'autres app, cela me semble acceptable.
>
>
> En général ça ne pose pas de problème ou plutôt ça en posera un quand il y
> aura des millions de contributeurs Jungle Bus qui éditerons tous
> ensemble... ce que j'appelle un "problème de riche".
>
> J'ai lu la doc d'install hier soir.
> L'installation a l'air assez documentée.
> Je vais tester en local dans les jours à venir.
>
>
> Teste sur un extrait, pas sur le planet... et SSD (rapide) indispensable
>
> Mais la version osm-fr était-elle standard ?
> A lire le wiki, j'ai l'impression que l'instance osm-fr a une
> amélioration pour permettre de s'en servir comme proxy d'édition.
>
>
> C'est un petit script au dessus d'overpass (et indépendant) qui permet de
> l'utiliser en lieu en place de l'API d'édition.
>
> --
> 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] Sécuriser Overpass API : quelles solutions ?

Le 21 juillet 2017 à 16:17, Christian Quest  a
écrit :

> Dans ton schéma, quel est le rôle de l'overpass ?
>
> Est-ce que ce n'est pas juste sa capacité à n'extraire que certaines
> données de la masse qui est utile ?
>
> Ne serait-il pas plus simple de prendre les hourly-diff, de les passer à
> travers osmfilter ou osmosis pour mettre à jour la base locale ?
>
> Je pense qu'overpass est un réel confort, mais qu'on en abuse trop
> souvent... (overpass <-> overkill)
>

C'est vrai, c'est une bonne idée.
En effet, l'overpass est exploité pour sa capacité à extraire.
+1 pour aller filtrer les hourly ou minute diffs, il faudra que je m'y
intéresse

Par ailleurs, utiliser un backend custom permet à la fois de gérer
différemment les envois vers OSM et vers les données du projet
La collecte peut ne pas porter exclusivement que sur des données OSM et par
conséquent il faut opérer un petit routage.
Si on le remplace par un overpass local, on perd cette possibilité

François

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

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Le 21 juillet 2017 à 16:26, marc marc  a écrit :

> Mais ma question était justement comment tu synchronises entre
> l'overpass api et la db locale ?
>

Ca va dépendre de plein de choses
On peut imaginer les choses les plus simples : tu vides ta base locale et
tu remplaces par le retour de l'overpass API (uniquement si toutes tes
données ne concernent qu'OSM)

Au choses les plus compliquées, avec la date d'édition, des références
métier pour le dédoublonnage (ma préférée) puis UPDATE sur conflit avec un
index unique ou insertion
Il reste le cas des suppressions qui est un poil pénible, bien qu'on puisse
ici travailler avec les ID OSM (un des rares cas où on peut le faire)


>
> Vu que les minutes diff existent et que Christian dit qu'on peux les
> filtrer, ne serrais-ce pas plus efficace que l'overpass api français (ou
> n'importe quel autre) exporte un minute-diff filtré ?
> Ainsi dans la minute tu as les modifs avec 0 query les 99.99% du temps
> où rien n'a été modifié sur les objets concernés.
>
oui c'est vrai que c'est encore mieux, l'avantage des diff étant de ne pas
avoir à détecter les create/modify/delete puisque c'est déjà indiqué dedans
On pourrait remplacer l'overpass avec les diff + un bon filtre

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

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Le 21 juillet 2017 à 15:11, marc marc <marc_marc_...@hotmail.com> a écrit :

> Le 21. 07. 17 à 14:21, François Lacombe a écrit :
> > Par contre, est-ce utile et justifié de monter une instance overpass en
> > ayant préalablement épuré le jeu de données à ce qui nous intéresse
> > uniquement ?
> > Remonter un backend conforme à l'API central pour l'édition, qui
> > dupliquerait le flux d'édition à la fois dans la base locale et sur OSM
> > d'une part et qui permettrait de charger ces données dans l'appli
> > frontend sur une bbox d'autre part ne requiert pas la puissance (et
> > complexité adjacente) d'overpass.
> Je n'ai pas compris ce que tu voulais dire.
> Sous quelle forme Jungle Bus pourrait garder un cache local avec
> supposons les 2 millions d'objet qu'elle utilise ? et surtout par quel
> moyen les garder à jour tant pour les contributions faite par l'appli
> que celle faite par les contributeurs osm ?
>

Un dessin vaut mieux qu'un long discourt
http://imgur.com/a/g4ec4

J'utilise ce genre de chose (sans l'ecriture vers OSM) depuis quelques mois
et ca tourne plutôt bien

Évidemment j'indique une sycnhro toutes les heures, mais même en le faisant
toutes les 5 minutes on réduirait grandement la charge sur l'overpass par
rapport à une adhérence directe avec le terminal du contributeur.

Le problème de la contribution multiple se retrouve lorsqu'on fait de
l'édition hors ligne.

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

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

Le 21 juillet 2017 à 18:02, Christian Quest  a
écrit :

>
> ... ne s'est-on pas bien éloigné du sujet initial ?
>

Il ne me semble pas : Florian voulait trouver une solution aux soucis de
dispo avec l'Overpass
La solution : se passer de l'overpass et faire de l'osmfilter sur les diffs

En tout cas c'est super interessant
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

2017-07-22 Thread François Lacombe

Bonsoir

Le 22 juil. 2017 8:47 PM, "marc marc"  a écrit :


Ce genre de projet doit faire des stats anonyme de ce qu'il consomme.
Tant que le volume est petit comme tu le décris, c'est acceptable de le
faire sur un overpass public.


Mmm le but du projet est d'etre mondial et de recontrer une large adhésion.
Nul besoin de passer par la case petite infra, il faut concevoir les choses
en conséquence dès le depart
Quand le projet est lancé on aura plus de mal a trouver le temps de tout
refondre parce qu'on aura rencontré sa cible


> On peut imaginer de demander à l'utilisateur de zoomer
> plus pour un niveau de zoom minimum 13 ou 14)
Si la taille de la bbox est 2 fois + petite, la requête serra évidement
2x + légère. mais ce n'est pas la piste la plus spectaculaire.


Je ne crois pas que ce soit vrai
L'overpass traite la selection avant la bbox (ou a traité par le passé)
Donc non, une bbox plus petite ne résoudra pas ton problème.
Et enfin, a quoi ressemblerait une appli sur laquelle on est obligé de
selectionner des petites bbox pour que ca reponde ?

Migrez vers une infra dont un cache local, ne perdez pas de temps
Surtout comme l'explique Florian que sa structure en a les moyens


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

Re: [OSM-talk-fr] DCNS devient Naval Group

2017-07-22 Thread François Lacombe

Bonsoir Jean Yvon

Le 22 juil. 2017 1:42 PM,  a écrit :

Bonjour,

Après RTE devenu Enedis, voici DCNS devenu Naval Group
.

Non non, RTE existe bien.
C'est erdf qui est devenu Enedis. Donc operator=ERDF => operator=Enedis dès
que possible, en ayant confirmé que operator=ERDF etait bien légitime.

Doit-on faire une note pour que les locaux de l'étape mettent à jour ?

Une requête overpass et modifier à la mano ?

A mon avis bonne technique
Un tel changement est aussi l'occasion de vérifier si les objets attribués
a DCNS sont bien les bons
Donc pas d'automatisme, surtout

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

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

2017-07-20 Thread François Lacombe

Hello Florian

Niveau robustesse il n'y a pas 36 solutions, il faut un cluster avec un
loadbalancer
Avec un bon hyperviseur, tu detruit carrement une vm qui plante pour en
remonter une aussi sec

Mais ca reste couteux alors il faut deja adresser ses requêtes a
différentes instances, au moins de et ru je pense

Ce qui est sur est que ca va vite couter un peu de monnaie pour monter une
infra disponible
CDN & co ne seront efficaces que pour des requetes courantes et surtout
abondamment utilisées, ce qui n'est majoritairement pas le cas

A+

François

Le 20 juil. 2017 9:08 PM, "Florian LAINEZ"  a écrit :

> Salut,
> Aujourd'hui on a eu -encore !- une interruption de service sur l'overpass
> API. Cela a impacté l'appli Jungle Bus mais j'imagine tout un tas d'autres
> services qui se basent dessus.
> J'ai l'impression que cela se produit souvent. Je constate dans mes
> projets que ce service reste le maillon faible technique et impose de
> mettre en place une pénible redondance.
>
> Est-ce que vous sauriez à quoi cela est dû ? Quelles en sont les causes
> profondes ?
> Y aurait-il une solution que nous pourrions mettre en place pour venir en
> soutien à nos amis les teutons qui gèrent le bouzin ?
> Est-ce plutôt un besoin de dev ou d’hébergement ?
> Bref, on résout le problème ? ;)
>
> --
>
> *Florian Lainez*
> @overflorian 
>
> ___
> 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] [OSM transport] Projet du mois - arrêts de bus

2017-07-04 Thread François Lacombe

Hello

+1 pour ref:FR
Avoir une clé dédiée permet à minima d'avoir des documentations et cas
d'usage séparés.
Le radical ref:FR permet de rattacher la référence a la liste des
references nationales plus facilement

Dans un projet aussi industriel que le notre, c'est pas rien

A+

Francois

Le 4 juil. 2017 08:48, "Ralf Treinen"  a écrit :

> Je ne sais pas d'ou vient exactement cette habitude d'utiliser un espace
> de noms :FR:. Une explication peut être que c'est au niveau national
> que les conflits potentiels vont être discutés et gérés. Remarquez
> que cette discussion est sur une liste nationale (et ni européenne,
> ni régionale).
>
> -Ralf.
>
> On Tue, Jul 04, 2017 at 08:23:22AM +0200, Pierre-Yves Berrard wrote:
> > On ne peut pas empêcher les doublons potentiels de ref: (y compris
> suffixé) à
> > un niveau géographique donné. Donc la raison du FR doit être ailleurs.
> >
> > Le mieux serait tout simplement "ref", mais un arrêt peut être utilisé
> par
> > plusieurs opérateurs, donc "ref:Stan".
> > À noter que c'était au départ "ref:STAN" mais cela a été changé suite à
> une
> > discussion locale, pour faire coïncider avec ce qui est affiché sur le
> site de
> > l'opérateur.
> >
> > PS : 44 est le code géographique de la région Grand Est.
> >
> > Le 4 juillet 2017 à 01:09,  a écrit :
> >
> >
> > Comme la dernière fois il y a les pour et il y a les contre.
> >
> > Je suis pour FR:STAN parce que si tu recherches un plan de ligne, tu
> veux
> > celui de la STAN de Nancy or les outils permettent de mettre un
> identifiant
> > de réseau qui doit donc être unique (on ne peut ajouter un pays
> ailleurs).
> >
> > On considère que la liste française permet d'éviter les doublons (et
> oui
> > ref:FR:44:Stan - 44 n'est pas un code de région mais de département,
> sinon
> > il faudrait mettre BZH ;-) mais c'est la TAN).
> >
> > Pour Rennes c'est FR:STAR.
> >
> > Par contre je vois aussi Lila. ou encore fr_tim.
> >
> > Bref, peu importe sauf qu'une ref pas unique alors que certains
> outils sont
> > basés juste dessus, bof.
> >
> > Mais homogène. J'ai aussi vu des ref simples mais des wikidata sur
> > l'operator. Toujours le même pb : les outils doivent connaître et
> utiliser.
> >
> > Sinon une partie simple (STAN) et une spéciale techos
> (operator:wikidata).
> >
> >
> > Le 04/07/2017 à 00:41, Pierre-Yves Berrard -
> pierre.yves.berr...@gmail.com
> > a écrit :
> >
> > Je laisserais simplement tel quel. Certes il y a un risque de
> récupérer
> > une entreprise de pneumatique au Pérou en faisant une requête sur
> > ref:Stan tout seul. Mais en général la référence n'est pas la clé
> > principale d'une requête (au minimum public_transport=platform
> et une
> > zone géographique éventuellement).
> >
> > Et s'il y a d'autres ref:Stan en France, il faudrait mettre un
> code
> > région : ref:FR:44:Stan ?
> >
> > PY
> >
> > Le 3 juillet 2017 à 23:29, Donat ROBAUX  a
> écrit :
> >
> > Ce serait moi, je basculerai tout en ref:FR:STAN pour éviter
> qu'à
> > l'autre bout de la planète ce tag ne serve à autre chose,
> parce
> > qu'on ne connait pas tout ce qui passe ailleurs. La
> catégorisation
> > par pays me semble éviter ces écueils, même si évidemment
> quand on
> > fait une requête, elle est limitée à la France.
> >
> > Donat
> >
> >
> > [icon-] Garanti sans virus. www.avast.com
> >
> >
> > Le 3 juillet 2017 à 23:12, Romain MEHUT <
> romain.me...@gmail.com> a
> > écrit :
> >
> > Bonsoir,
> >
> > Quelqu'un pour trancher si on doit basculer les ref:stan
> > (indiqué ici http://wiki.openstreetmap.org/wiki/Nancy/
> > Transports_en_commun) en ref:FR:STAN ? Et par la même
> occasion
> > harmoniser les pratiques sur toute la France...
> >
> > Merci.
> >
> > Romain
> >
> >
> > Le 2 juillet 2017 à 12:17, Ralf Treinen 
> a
> > écrit :
> >
> > Bonjour,
> >
> > ça ne devrait pas plustot être "ref:FR:Stan" ? Ici en
> > région parisienne
> > nous utilisons "ref:FR:STIF".
> >
> > -Ralf.
> >
> > On Sun, Jul 02, 2017 at 10:40:19AM +0200, Pierre-Yves
> > Berrard wrote:
> > > Bonjour Frédéric,
> > >
> > > La référence à utiliser est "ref:Stan". Cela
> devrait
> > faire disparaître la
> > > quasi-totalité des points verts. ;-)
> > >
> > > Pierre-Yves
> > >
> >

Re: [OSM-talk-fr] Plusieurs données libres qui pourraient améliorer osm

2017-07-06 Thread François Lacombe

Bonjour Jérôme,

Le 6 juillet 2017 à 02:40, Jérôme Amagat  a écrit :

> - Données sur les installations radioélectriques de plus de 5 watts (
> https://www.data.gouv.fr/fr/datasets/donnees-sur-les-installations-
> radioelectriques-de-plus-de-5-watts-1/ )
>
> il y a déjà eu une discussion en rapport avec cette donnée sur cette
> liste, et il n’y a pas les tags pour tout intégrer à osm mais une chose
> pourrait être intégrer c’est les supports des « antennes »
>
> ces supports sont classé dans différentes catégories :
> Sémaphore;Phare;Château d'eau - réservoir;Immeuble;Local
> technique;Mât;Intérieur galerie;Intérieur sous-terrain;Tunnel;Mât béton;Mât
> métallique;Pylône;Bâtiment;Monument historique;Monument religieux;Pylône
> autoportant;Pylône autostable;Pylône haubané;Pylône treillis;Pylône
> tubulaire;Silo;Ouvrage d'art (pont, viaduc);Tour hertzienne;Dalle en
> béton;Support non décrit;Fût;Tour de contrôle;Contre-poids au
> sol;Contre-poids sur shelter;Support DEFENSE;pylône arbre;Ouvrage de
> signalisation (portique routier, panneau routier, panneau
> publicitaire);Balise ou bouée
>
> Je pense surtout aux pylônes, tour hertzienne et mat qui pourrait être
> ajouté avec les tag man_made=tower ou man_made=communications_tower.
>

+1
On peut également compléter les tags operator=*, height=* et par conséquent
ref:FR:ANFR avec ces fichiers pour les supports de type pylônes, mats...
S'agissant de données ponctuelles, osmose est approprié pour faire la
conflation


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

Re: [OSM-talk-fr] application StreetComplete

2017-04-26 Thread François Lacombe

Hello,

Intéressant ce projet

Il faudrait rapprocher ça de MapContrib non ?
Créer des quêtes sur la base de thèmes créés dans MapContrib

Pour ma part, je vais essayer de pousser un petit quelque chose pour les
armoires de rue man_made=street_cabinet

A+

*François Lacombe*

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

Le 26 avril 2017 à 11:38, Marc <dkm+...@kataplop.net> a écrit :

> > Merci pour l'information - J'ai fait l'erreur d'utiliser l'application
> > streetComplete sur Android sans me référer au wiki.
> >>
> >
> > C'est l'utilisateur ou l'interface qui a un problème???
>
> Voici la question qui a été posée (cf pj)... je pense...
>
> ___
> 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] application StreetComplete

2017-04-26 Thread François Lacombe

Le 26 avril 2017 à 14:05, Eric SIBERT  a écrit :

> Il y a une internationalisation de l'interface prévue?
>

Il y a un projet en cours sur POEditor
https://poeditor.com/join/project/IE4GC127Ki

French est à 100%


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

[OSM-talk-fr] Carte collaborative des arbres fruitiers

2017-04-26 Thread François Lacombe

Bonsoir,

Je viens de voir passer cet article du monde qui parle du site
FallingTrees.org
http://linkis.com/www.lefigaro.fr/cons/P9vv7

Le principe semble être de cartographier les arbres fruitiers du monde
entier pour ramasser ses fruits soit-même.

L'initiative est très bonne, le côté collaboratif est évidemment séduisant.

SAUF

que le site affiche un fond Google Maps, OSM n'a pas du faire partie des
solutions étudiées, d'autant que des petits nœuds natural=tree seraient
vraiment sympa à ajouter à la base.

Ça aurait du s'appeler FailingFruits.org :(

Bonne soirée

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

Re: [OSM-talk-fr] OpenData RTE dans Osmose-QA

2017-04-25 Thread François Lacombe

Hello,

C'est vrai que je n'avais pas vu tout ces problèmes.

D'accord avec vous pour créer deux points distincts
Une relation de type site semble lourd mais pour autant le bon outil parce
qu'il n'y a pas de périmètre fermé pour entourer tout ces éléments
Parfois il y a deux points géodésiques sur le même pylône, je l'ai vu
récemment (il y a donc 3 nœuds, même aujourd'hui, dans la base)


A+

*François Lacombe*

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

Le 25 avril 2017 à 10:24, Vincent Pottier <v...@frvipofm.net> a écrit :

> Le 23/04/2017 à 11:03, Art Penteur a écrit :
>
>> C'est l'occasion de poser la question du codage des pylônes qui
>> portent un point géodésique.
>>
>> Exemple : http://www.openstreetmap.org/node/670155064#map=17/44.41231/
>> 1.41735
>>
>> Quelle solution fait consensus, actuellement ?
>>- 1 seul nœud avec tous les attributs (power-=tower et  man_made
>> survey_point). ça a une certaine cohérence physique, mais pose des
>> problèmes de codage (par exemple, comment combiner la ref IGN et la
>> ref RTE) ?
>>- 2 nœuds très proches (éventuellement liés par une relation de type
>> site)
>>- créer un polygone power=tower, avec un nœud à chacun des pieds du
>> pylône, avec le survey_point naturellement à l'intérieur du polygone
>> (mais la page wiki de power=tower interdit les polygones) ?
>>- autre ?
>>
>> Art
>>
>> Bonjour,
>
> Le nœud survey_point comporte un tag ele qui vaut pour l'altitude du
> repère et non celle du pylône, celle-ci étant considérée au pied de ce
> dernier, au niveau du sol.
>
> Le pylône est un objet propre avec ses propres coordonnées, sa propre
> altitude, le repère en est un autre : d'où deux objets différents.
>
> En ne gardant qu'un seul nœud, on induit une erreur, de considérer le tag
> ele comme étant l'altitude du pylône.
>
> Après, reste à voir comment relier les deux.
>
> FrViPofm
>
>
> ___
> 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] Comptage trafic routier

2017-04-30 Thread François Lacombe

Hello

Le 30 avril 2017 à 12:26,  a écrit :

> Tu es un peu dur, la population est aussi une donnée variable qui a sa
> place dans OSM.
>

Oui c'est un peu binaire.

Je préfère ajouter un code wikidata et joindre avec une base ayant un
rythme de mise à jour différent pour récupérer ces données.
Parce qu'on va pousser ces valeurs - potentiellement en masse - dans OSM
mais rien ne garenti leur mise à jour et le suivi.


> En théorie, la théorie c'est comme la pratique. En pratique...
>

Tout à fait, c'est dans cette optique que je pensais à la maintenance de
tout ça

Enfin c'est mon avis, à débattre


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

Re: [OSM-talk-fr] Problème pour taguer un poste de gaz

2017-08-04 Thread François Lacombe

Bonsoir

Lionel,
D'après la photo  du poste de Cenon sur Vienne :
ref=38292
name=Cenon-sur-Vienne DP

le "DP" à la fin doit servir à déterminer la valeur de substation=*, mais
pas encore trop d'infos sur la question pour l'instant.
On pourrait directement mettre substation=DP pour le retravailler
facilement plus tard si nécessaire.

Christian,
C'est très sain de faire son footing en relevant ce genre de POI ;)

Le 4 août 2017 à 11:09, David Crochet  a écrit :

> Une source avec de meilleurs précisions, surtout lorsque les balises ne
> sont plus visible en photographie aériennes, ce sont les servitudes
> d'utilité publique de type i3 (transport de gaz naturel par canalisation)
> disponibles sur certains documents administratifs édictées par les
> préfectures
>

+1 avec David

Et les générateurs (les pipelines) de ces servitudes sont maintenant
disponibles sur data.gouv pour certains départements
http://www.data.gouv.fr/fr/search/?q=servitudes+i3

Si le votre n'est pas dans la liste, il faut motiver la DDT :)

A+

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

Re: [OSM-talk-fr] Création de la liste OSM tagging-fr

2017-08-19 Thread François Lacombe

Bonsoir Severin,

Merci pour l'info et pour la création de cette ML :)

En ce qui concerne la proposition de nouveaux tags, les choses ne sont pas
toujours faciles à suivre : des échanges peuvent prendre place à différents
endroits.
Notamment le wiki (Talk), la ML internationale @tagging, maintenant sur
tagging-fr en passant par les discussions locales et les forums

Vu que tout le monde n'ira pas s'abonner aux ML, c'est important de
reporter les conclusions des échanges et le périmètre auxquelles elles ont
été établies au moins sur le wiki.
Sinon c'est un enfer, on apprend par la bande que la clé qu'on pensait
utiliser est comprise d'une autre manière ou est en conflit ailleurs dans
le monde (entres autres)

Pour le reste et parce que les échanges autour des tags ne se limitent à
l'introduction de nouveauté, ce sera avec plaisir qu'on pourra parler du
sens de l'existant :)

A+

François

*François Lacombe*

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

Le 19 août 2017 à 22:16, Severin Menard <severin.men...@gmail.com> a écrit :

> Bonjour à tous,
>
> Ce courriel pour vous annoncer la création de la liste de discussion OSM
> tagging-fr <https://lists.openstreetmap.org/listinfo/tagging-fr>destinée
> aux discussions sur les tags OpenStreetMap entre francophones, afin de
> permettre des échanges plus faciles sur ce thème entre tous ceux qui sont
> plus francophones qu'anglophones et rendre enfin possible l'apport des
> contributeurs OSM francophones peu ou pas du tout anglophones qui en
> étaient jusqu'ici complètement exclus.
>
> Pas de méprise : le tagging qui sera discuté en français à travers cette
> liste sera toujours en anglais. Le but est de permettre un apport plus
> conséquent des francophones sur le tagging OSM, non seulement dans les
> différents contextes purement francophones, mais également sur les tags les
> plus génériques, et d'échanger avec la liste mondiale tagging dès qu'une
> proposition semblera faire sens.
>
> A mon étonnement, il semble que cette déclinaison de la liste tagging pour
> une communauté linguistique particulière soit la première du genre. Nous
> verrons si d'autres suivent le même chemin.
>
> ___
> 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] Retour sur le State of the Map 2017 (Japon)

2017-08-22 Thread François Lacombe

Bonjour Adrien et merci pour ce compte rendu.

Je serai très intéressé par le comparatif sur les outils de routage.
Est-ce qu'il y a de la documentation quelque part ou les slides sont
visibles en ligne ?

Je ne connaissais pas bute de geofabrik par exemple

A+

François

*François Lacombe*

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

Le 22 août 2017 à 16:02, PanierAvide <panierav...@riseup.net> a écrit :

> Bonjour à tous,
>
> Cette année, trois contributeurs français se sont rendus à la rencontre
> annuelle mondiale d'OpenStreetMap : le State of the Map, qui se déroulait
> au Japon.
>
> Un retour d'expérience (écrit collaborativement) est disponible sur :
> http://openstreetmap.fr/sotm-japon-2017
>
> Cordialement,
>
> Adrien.
>
>
> ___
> 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] Création de la liste OSM tagging-fr

2017-08-20 Thread François Lacombe

Le 20 août 2017 à 20:37,  a écrit :

> Mais comme dit malicieusement François, si vous voulez, allez parler de
> nouveaux tags là-bas, on continuera de parler des tags ici
>

Ce n'était pas exactement ce que je voulais dire.
On parle bien des tags où on veut, le problème c'est que les conclusions
des discussions sont rarement capitalisées dans le pot commun.
Donc on peut bien en parler, mais si personne ne le sait il ne se passera
jamais rien


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

[OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

2017-08-20 Thread François Lacombe

Bonsoir à tous,

Il y a actuellement des discussions en cours autour de la carto des bornes
à incendie.
Services d'urgence et Bnhynoteam, c'est pour vous

https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions

Globalement ca tourne autour de l'ordre à mettre dans certaines clés.
Et ajouter quelques renseignements supplémentaires :
- Tailles et types de connecteurs
- Couleurs, dispositifs réfléchissants
- Type de clés nécessaires pour ouvrir les bouches

De mon point de vue, les namespaces fire_hydrant: et suction_point:
devraient être supprimés pour avoir des clés plus légères et polyvalentes.
On a aussi discuté de la pertinence de regrouper les bornes pressurées et
les points de captage sous une même clé emergency=water_supply (ou
apparenté), mais apparemment ça ne fait pas l'unanimité.

Bref, si vous avez des remarques ou des retours à faire, c'est le moment
avant le vote qui aura lieu après que tous les points ouverts à la
discussion ne soient refermés.

Vu qu'il y a une nouvelle liste tagging-fr à laquelle tout le monde n'est
pas encore abonné, j'ai envoyé ce mail aux deux ML ;)

A+

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

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

2017-08-20 Thread François Lacombe

Hello,

En fait, certains ont sorti l'arme fatale qu'il y avait deja beaucoup trop
d'objets emergency=fire_hydrant pour en changer vers quelque chose de plus
cohérent
En plus de l'argument de Viking qui veut des données taillées pour
alimenter les GPS de ses collègues.
Je ne suis pas trop d'accord avec les deux idées, néanmoins en faisant le
compromis là-dessus, j'espère qu'ils accepteront de supprimer fire_hydrant:
et suction_point: du noms des clés :)

Pour le split, si il n'y a pas d'harmonisation entre fire_hydrant et
suction_point, tout peut être traité d'un seul coup non ?


François

Le 21 août 2017 à 02:02, marc marc  a écrit :

> et la proposition est de qualité même si comme toi, je pense qu'il
> aurait fallu profiter de l'occasion pour harmoniser +.
>
> Il serrait pratique qu'il coupe sa propal en 2 pour faire voter la
> première partie où il semble y avoir une unanimité même si on chipote
> encore sur certains détails.
> ___
> 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] Bornes à incendie : proposition en cours d'écriture

2017-08-22 Thread François Lacombe

Bonsoir à tous,


Le 21 août 2017 à 23:21, marc marc  a écrit :

> si tu les connais, préviens les qu'ils ne réagissent pas ici.
>

C'est fait ici : https://twitter.com/InfosReseaux/status/899711313781436420


>
> il est vrai que la proposition concerne aussi le tag flow_capacity
> ce n'est pas la même chose que si la proposition n'en parlait pas.
> Donc en effet autant voter sur quelque chose d'abouti.
> Mais voilà, je ne vois pas exactement le problème avec flow_capacity
> capacity:flow je trouve flow assez générique. vois-tu un autre tag avec
> flow possible ? parce que sinon c'est un peu l'inverse de type, ce serra
> un tag tellement précis qu'il n'existe qu'avec capacity et dans ce cas
> flow_capacity serrait tout aussi bien.
> Si t'as un exemple d'autre "flow", je me rangerai à ton avis.
>

Je suis ok pour dire que ce n'est que de la forme et je n'ai pas trouvé
d'autre clé qui puisse aller avec flow.
N'ajoutant dans OSM que des données statiques, il ne peut s'agir que d'une
capacité.

Le seul argument est que capacity existe, qu'on peut l'exploiter et il
était intéressant de regrouper la capacité en débit et en connexions sous
la même clé
Un peu comme ref=*, qui est un bon exemple : tout ce qu'il traite ne peut
être que des références, pourtant on l'a bien segmenté pour des raisons
évidentes de documentation et de collisions.
On a pas fait de INSEE_ref, mais ref:FR:INSEE ou de erdf_ref mais
ref:erdf:gdo, etc...


pourquoi rajouter un nouveau tag à discuter ? la proposition ne touche
> pas à ce tag, c'était mauvais, cela reste mauvais, cela reste à
> améliorer. sinon au final on se trouve avec une propal pour résoudre
> tous les défaut d'osm (je caricature volontairement fortement) mais qui
> reste non adoptée.
>
Parce que c'est dans le sujet traité et que le temps manque aussi.
Là on est quand même assez raisonnable je trouve :)
Et même en ajoutant deux tags, on est loin de tout avoir traité. Il restera
bien quelques propositions à faire avant d'avoir un modèle complet. Tout
l'aspect des connexions (hormis les clés coupling) n'est pas traité et là
je suis d'accord de ne pas le faire car c'est vaste.


> > Ne pas discuter des points pour accélérer ne m'attire pas trop.
> mon avis n'est pas dans ce sens.
> je voulais dire "diviser pour aboutir", un pas après l'autre
>
C'est quand même ce que nous faisons, la description est pas encore
complète et ne le sera pas à l'issue du vote de cette proposition
Meme en ajoutant les deux clés sous capacity.

Je te laisse le mot de la fin ayant donné toutes mes billes sur le sujet
pour voir ce qu'on fait remonter à Viking :)


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

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

2017-08-22 Thread François Lacombe

Le 23 août 2017 à 00:12, marc marc <marc_marc_...@hotmail.com> a écrit :

> Le 22. 08. 17 à 22:58, François Lacombe a écrit :
> > il est vrai que la proposition concerne aussi le tag flow_capacity
> > capacity:flow je trouve flow assez générique. vois-tu un autre tag
> avec
> > flow possible ? parce que sinon c'est un peu l'inverse de type, ce
> serra
> > un tag tellement précis qu'il n'existe qu'avec capacity et dans ce
> cas
> > flow_capacity serrait tout aussi bien.
> > Si t'as un exemple d'autre "flow", je me rangerai à ton avis.
> > Je suis ok pour dire que ce n'est que de la forme et je n'ai pas trouvé
> > d'autre clé qui puisse aller avec flow.
> j'ai trouvé ton sauveur :) il y a bien capacity:disabled alors qu'il n'y
> pas d'autre clef :disabled
>

Il y a aussi sur la page du wiki :parent qui selon taginfo est seul (il y a
des :parent mais dans le sens de l'ascendance et pas du rôle de
parent/enfants)

capacity:flow va aussi servir pour les pipelines (en remplacement du
"free-text" capacity pour l'instant) et des choses comme waterway=drain et
tunnel=culvert
Il y a les prises d'eau en rivière aussi, il y a vraiment plein de cas
d'utilisation.


> alors pourquoi pas capacity:flow si tu penses que c'est utile.
> cela m’embête un peu parce que je trouve ennuyeux qu'on casse l'unicité
> de l'unité par défaut de capacity (nombre sans unité).
> mais vas-y si tu penses que capacity:flow est bien mieux que flow_capacity
>

Je pense aussi que si la situation est celle-ci aujourd'hui, c'est que le
cas ne s'est pas présenté.
Connaitre le dimensionnement d'une infrastructure est pas si facile que ca
et en dehors des places de parking ou de lit d'hotel, ce n'est pas ce qui
intéresse en premier.
Et il y a bien une unité à toutes ces grandeurs. Elles n'ont par contre pas
de dimension (un detail ce dernier point, j'ai compris ce que tu voulais
dire).
Au niveau industriel, c'est hyper intéressant pourtant et ca place OSM loin
loin devant toute l'opendata que les acteurs intéressés peuvent aujourd'hui
produire.


> > pourquoi rajouter un nouveau tag à discuter ?
> > la proposition ne touche pas à ce tag
> > Parce que c'est dans le sujet traité et que le temps manque aussi.
> Je n'ai pas compris. niveau temps, il vaut mieux circonscrire la
> proposition au lieu de l'étendre chaque semaine, non ?
>

Non, c'est qu'en ce moment nous y consacrons tous du temps, autant en tirer
un maximum de profit (de tag, de cas décris et connus,...)
Plus tard, nous aurons peut-etre tous autre chose à faire, c'est dans ce
sens là que je l'entendais

J'ai ça à faire voter également bientôt quand j'aurais fini les dernier
réglages
https://wiki.openstreetmap.org/wiki/Proposed_features/Transformer_extension_proposal

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

Re: [OSM-talk-fr] Vérification

2017-05-14 Thread François Lacombe

Bonsoir

Les amis de wikipedia ont traité le sujet. Il y a les adresses associées

https://fr.m.wikipedia.org/wiki/Liste_des_fa%C3%A7ades_factices_de_Paris

A+

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

Re: [OSM-talk-fr] Formaliser les informations des armoires techniques Fibre

2017-06-08 Thread François Lacombe

Bonsoir Baptiste,

Ce sujet de carto fait partie de ceux que j'affectionne aussi.
Il concerne à la fois l'infrastructure avec l'inventaire de composants clés
dans le déploiement de certains réseau, mais aussi de la simple
accessibilité des trottoirs.

Je suggère de remplacer ref:FR:IPON par ref:FR:Orange qui semble plus
adapté à une utilisation par des non initiés.
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:Orange

Ce qui donnerait donc dans ton exemple
ref:FR:Orange=FI-29019-001C
ref:FR:Orange:NRO=BRC
ref:FR:Orange:PT= PT0519

Quelques explications supplémentaires sont dispos sur la page, n'hésites
pas à revenir ici si tu en souhaites d'avantage.

Plus largement sur la carto des armoires de rues, il faut regarder du côté
de man_made=street_cabinet
https://wiki.openstreetmap.org/wiki/FR:Tag:man_made%3Dstreet_cabinet

A+

François

Le 18 mai 2017 à 10:45, Baptiste Mille-Mathias <
baptiste.millemath...@gmail.com> a écrit :

> Bonjour,
>
> Je vous contacte car je débute dans la cartographie et je voudrais un peu
> de conseil concernant les armoires technique fibre, il y a quelques-unes
> autour de chez moi et j'aimerai les ajouter.
>
> Ce sont des armoires comme décrites dans la page wiki
>  qui
> porte une mention du genre AXE2 FI-06085-000B PT8 et je voudrais
> comment / où reporter ces informations.
>
> je n'ai pas vu de mention spécifique pour la fibre dans le wiki
> , et
> en cherchant l'utilisation du tag telecom:medium=fibre
>  je suis tombé sur différent cas, de la simple
> utilisation du champs description ou ref avec la valeur récupérée sur
> l'armoire à l'utilisation de 3 tags ref:FR:IPON, ref:FR:IPON:NRO,
> ref:FR:IPON:PT (exemple )
> ce qui donnerait
> ref:FR:IPON=AXE2
> ref:FR:IPON:NRO=06085000B
> ref:FR:IPON:PT=PT8
>
> Y a t'il une norme à suivre ? que me conseillez-vous ?
>
> Merci
> --
> Les gens heureux ne sont pas pressé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] Comptage trafic routier

2017-04-29 Thread François Lacombe

Bonsoir Julien,

A mon avis, en France la hiérarchisation des axes routiers suffit pour
définir le type de highway (du moins pour choisir entre primary, secondary,
...)
Quoi que le comptage permettrait effectivement de placer l'usage en tout
premier plan.
Ca me fait penser à ca : https://pbs.twimg.com/media/BwoLExaCEAA58Ll.jpg

Le comptage en tant que tel est une donnée variable qui n'a pas sa place
dans OSM.

En revanche il est très intéressant d'indiquer l'emplacement des boucles de
comptage et armoires de collecte associées avec les clés
man_made=monitoring_station et man_made=street_cabinet
Regarder également du côté de monitoring:traffic=yes
De telles stations peuvent avoir une disposition complexe avec une même
armoire gérant des boucles installées sur plusieurs voies. Il convient
ainsi d'indiquer man_made=street_cabinet sur l'armoire et de mettre toutes
les boucles en relation avec une relation de type=site +
man_made=monitoring_station
Je ne connais pas de valeur pour les boucles de comptage, on peut penser à
highway=induction_loop

Pour mémoire, une boucle de comptage ressemble à ca :
http://www.lacroix-city.com/fileadmin/IMAGES/Produits/TRAFIC_URBAIN/Detection_de_trafic/LACROIX_Trafic_Urbain_boucle__slider01.jpg

Voir également :
https://fr.wikipedia.org/wiki/Syst%C3%A8me_informatis%C3%A9_de_recueil_de_donn%C3%A9es


A+

François

Le 29 avril 2017 à 21:27, djakk  a écrit :

> Salut,
>
> est-ce que les comptages de trafic routier réalisés par les DIR ou les
> départements peuvent être utilisés pour définir les types de "highway" (on
> a
> le droit ? c'est intéressant ?) (exemple avec l'Ille-et-Vilaine :
> http://www.ille-et-vilaine.fr/sites/default/files/asset/
> document/carte_2014_des_trafics_moyens_journaliers_sur_les_routes_
> departementales_et_nationales_en_ille-et-vilaine.pdf)
> Et est-il possible/souhaitable d'intégrer un comptage dans osm (sous la
> forme d'un nœud) ?
>
> Julien "djakk" (http://itineraires.de.bus.free.fr)
>
>
>
> --
> View this message in context: http://gis.19327.n8.nabble.
> com/Comptage-trafic-routier-tp5896091.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> 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] Label HQE

2017-05-06 Thread François Lacombe

Bonsoir à vous,

Pas d'infos sur l'intégration des bâtiments BBC ou HQE

Si toutefois cela peut vous aider, il y a cette proposition pour intégrer
entre autre le type d'isolation thermique ou phonique des bâtiments.
Toujours en draft parce que pas pris encore le temps de la finaliser,
notamment au niveau des exemples et cas d'usage
https://wiki.openstreetmap.org/wiki/Proposed_features/Insulation_proposal


A+

*François Lacombe*

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

Le 6 mai 2017 à 19:41, Stéphane Péneau <stephane.pen...@wanadoo.fr> a écrit
:

> Les Allemands étant un peu en avance, et proposant le label passivhaus qui
> décrit des performances thermiques, j'ai cherché s'il existait dans Osm.
>
> Rien...nada !
>
> Le 06/05/2017 à 17:21, osm.sanspourr...@spamgourmet.com a écrit :
>
>>
>> De plus en France c'est du déclaratif, personne ne vérifie si les
>> critères sont remplis effectivement (expertise post réalisation), idem pour
>> la RT2012.
>>
>>
> C'est HS, mais si, il y a des vérifs pour le RT2012 (étanchéité entre
> autres).
>
> Stf
>
> ___
> 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] Devenir mandataire d'OpenStreetMap France

2017-10-09 Thread François Lacombe

Bonsoir cher Président

Merci pour cette intéressante initiative.
J'ai inscrit mon nom en face de la case réseaux. Ca correspond aux
contributions que j'affectionne et au discours que je tient sur OSM et
l'aménagement du territoire (Poliment c'est un TOC)

Au plaisir d'en savoir plus, si cette éventualité se concrétise

Bonne soirée

François


*François Lacombe*

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

Le 9 octobre 2017 à 17:47, Nicolas Moyroud <nmoyr...@free.fr> a écrit :

> Salut grand chef,
>
> Ça c'est une initiative qu'elle est bonne.
>
> Donc
>> ... si partager votre enthousiasme pour le projet OSM vous plaît
>> ... si vous savez dégager un peu de temps pour des actions associatives
>> ... si vous vous sentez légitime sur des sujets métiers en lien avec OSM
>> ... si animer une cartopartie, tenir un stand OSM, répondre au
>> journaliste du coin selon l'occasion vous motive
>>
> J'ai répondu oui aux 4 points de ton message est-ce que c'est grave
> docteur ? Du coup zou je m'inscris de ce pas sur le pad (il serait temps !).
>
>> D'ici quelques semaines, l'idée est de pouvoir matérialiser ce collectif,
>> de l'organiser, mutualiser quelques ressources, économiser l'énergie de
>> chacun tout en répondant mieux aux sollicitations.
>>
> Soirée ti'four et champ' dans un château aux frais de l'asso ? C'est un
> bon moyen d'avoir plein de mandataires ça ! ;-)
>
> Nicolas
>
>
> ___
> 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] Bornes à incendie : proposition en cours d'écriture

Le 28 août 2017 à 11:32, marc marc  a écrit :

> Je trouve que ce n'est pas exact.
> capacity indique le maximum possible pour une infrastructure.
> le chiffre indiqué sur une borne incendie n'est pas son débit
> variable dans le temps (celui là ne dépend que du pompier)
> mais le débit maximum dont la borne est capable.
>
Je suis de cet avis, mais tout le monde n'entend pas cette logique.
Ils ont migré vers flow_rate, ce qui est déjà un progrès.


> On fait quoi pour la séparation pressurisé <> non pressurisé ?
> j'argumente une dernière fois avec le fait que 10% des bornes françaises
> vont se trouver dans un état indéterminée pas d'info pour les classer ?
> et surtout quid à l'avenir du gars qui rencontre une borne
> sans plaque de pression... il doit choisir l'une des 2 catégories,
>

Pareillement, je suis de ton avis.
dans l'immédiat, avoir des clés agnostiques de fire_hydrant ou
suction_point est déjà une avancée.
On peut partir la dessus pour l'instant et dans un second temps revenir en
force avec des cas et propositions dans ce sens ?
Comme tu le disais, sinon ca risque d'échouer si on fait tout en même temps


>
>  > attends tu l'avis Bhynoteam ?
>  >
>  > Yann Kacenelen m'a répondu sur Twitter avec ce document qu'il avait
>  > rédigé en 2015
>  > https://framagit.org/ykacenelen/point_eau_incendie_OSM/snippets/655
> J'ai lu son document.
> ä un endroit il dit qu'il n'est pas pour type=pond
> ä un autre il propose l'ajout de type=dry_hydrant qui n'est
> cependant pas en jaune comme le reste des nouveauté proposé.
> je ne sais pas si l'un est un remplacement de l'autre.
> En fin de pdf, il utilise donne des exemples de bornes sans pression :
> emergency = fire_hydrant
> fire_hydrant:type = pillar
> fire_hydrant:pressure = suction
> Donc j'en déduit que selon lui, il faudrait aussi supprimer le "pond"
> mais que le critère d'uneborne n'est pas la pression
> il ne compte pas participer au débat ?
>
Non à mon avis il n'a pas le temps
Le document étant principalement en phase avec la proposition hormis les
clés avec fire_hydrant: de partout, je suis d'avis pour le soutenir en
l'état.

Il reste peut-être un point sur couplings_type et couplings_diameter qui
sont là pour décrire les types de connexion et surtout leur nombre et
diamètre.
Peut-être suggérerais-je l'ajout de manufacturer=* et model=* qui
pourraient servir à connaitre le modele de borne (standard dans le
catalogue fournisseur) sans avoir à préciser exactement les diamètres et
types de connexion (pas forcément visibles en plus)
Alors que des fabricants il n'y en a pas des masses (bayard,...)

Les points Resolved commencent à apparaitre dans le Talk, ce qui est bon
signe

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

Re: [OSM-talk-fr] MAJ BDOrtho ??

Hello,

Je profite de la discussion pour demander si on peut accéder à d'anciennes
versions de la BDOrtho ?
Sans parler de la machine à remonter le temps du Géoportail, ce pourrait
être sympa d'avoir des vues aériennes du début 2000 ou fin 90 de certaines
zones.

Un ou plusieurs TMS serait un luxe insolent, mais je ne désespère pas ;)

François

*François Lacombe*

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

Le 29 août 2017 à 16:45, HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT
GE APPUI PERFORMANCE) <denis.hel...@reseau.sncf.fr> a écrit :

> Il ne faut pas oublier des IDG qui annoncent leurs collaborations avec
> l'IGN en matière, entre autres, de production de l'orthophotoplan.
> CIGAL dans le Grand Est par exemple : https://www.cigalsace.org/
> geonetwork/apps/georchestra/
>
> Denis
>
>
> -Message d'origine-
> De : Stéphane Péneau [mailto:stephane.pen...@wanadoo.fr]
> Envoyé : mardi 29 août 2017 16:27
> À : Discussions sur OSM en français <talk-fr@openstreetmap.org>
> Objet : [OSM-talk-fr] MAJ BDOrtho ??
>
> Bonjour,
>
> Certains auraient remarqué une mise à jour de l'imagerie aérienne de la
> BDOrtho ?
>
> Moi oui, depuis aujourd'hui, au moins sur le sud de la loire-atlantique.
>
> D'ailleurs, j'avais tracé un nouveau giratoire depuis une trace en RTK, et
> la correspondance est pas mal du tout :
> https://www.openstreetmap.org/way/371573209
>
> Stf
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> ---
> Ce message et toutes les pièces jointes sont établis à l'intention
> exclusive de ses destinataires et sont confidentiels. L'intégrité de ce
> message n'étant pas assurée sur Internet, la SNCF ne peut être tenue
> responsable des altérations qui pourraient se produire sur son contenu.
> Toute publication, utilisation, reproduction, ou diffusion, même partielle,
> non autorisée préalablement par la SNCF, est strictement interdite. Si vous
> n'êtes pas le destinataire de ce message, merci d'en avertir immédiatement
> l'expéditeur et de le détruire.
> ---
> This message and any attachments are intended solely for the addressees
> and are confidential. SNCF may not be held responsible for their contents
> whose accuracy and completeness cannot be guaranteed over the Internet.
> Unauthorized use, disclosure, distribution, copying, or any part thereof is
> strictly prohibited. If you are not the intended recipient of this message,
> please notify the sender immediately and delete it.
> ___
> 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] Distinction power line/minor_line en France

Hello à tous,

TL;DR : abaissons au niveau français la limite entre power=minor_line et
power=line à 10 000 volts.
- Pour taguer le 20 000 vols et la base tension sur les mêmes appuis, seuls
cas où une telle cohabitation se présente
- Les lignes > 30 000 volts sont visuellement impactantes et des éléments
utiles à l'orientation qui doivent être représentées en tant que telles.
Pour ou contre ?

Je viens de re-lire le paragraphe
https://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/France#Lignes_a.C3.A9riennes
indiquant que power=minor_line pouvait avoir une réalité sur les réseau de
transport d'énergie, notamment lorsqu'ils étaient supportés sur les mêmes
poteaux que les réseaux basse tension.
De mon point de vue, ce n'est jamais le cas.
Le réseau de transport assure le transit de l'électricité entre les grandes
centrales et les bassins de consommation. Il est relayé par la distribution
jusqu'aux consommateurs.

Avec votre accord (ou sans réaction à ce mail), je souhaiterais déplacer le
point line/minor_line dans la partie réseaux de distribution, parce que le
réseau de transport doit être à 100% décrit avec power=line.

Initialement partisan de l'abandon pur et simple de minor_line, je pense au
compromis suivant:
Compte tenu des distances imposées par les tensions auxquelles les lignes
aériennes sont exploitées, minor_line ne saurait être utilisé sur des
lignes > 30 000 volts.
Ce serait évidemment beaucoup mieux, au niveau français, d'établir une
limite ferme à 10 000 volts
Au dessus de cette limite les lignes deviennent visuellement impactantes et
de bons éléments pour s'orienter. C'est donc un débat 100% distribution.
D'autre part, cela permettrait à ceux qui le souhaitent de cartographier
également les lignes basse tension très capillaires sans collisions avec
les réseaux de plus grande importance. On peut avoir de gros soucis quand
le 20 000 volts partage des supports avec la basse tension (ce sont les
seuls cas connus) et ainsi minor_line et line nous permettraient de faire
cohabiter ces éléments.
Visuellement ca colle aussi, et donc cela pourrait contenter ceux qui
affectionnent le rendu.

Au niveau mondial, la discussion n’aboutit pas vraiment, entre ceux qui
souhaitent une description usage/fonction, d'autres pour le rendu. Et les
données sont parfois inextricables pour pas grand chose. Il y a des défis
beaucoup plus structurants en ce moment.
Peut-être parce que c'est un débat local, avoir une situation homogène sur
la France serait déjà un grand pas en avant.

Bonne journée

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

Re: [OSM-talk-fr] Distinction power line/minor_line en France

Le 30 août 2017 à 11:25, marc marc  a écrit :

> je le trouve indigeste parce qu'il bascule entre 2 critères sans qu'on
> sache clairement à la fin qu'est-ce qui est unanime et qu'est-ce qui est
> contesté
>
Oui, pas de consensus. Donc on ne peut qu’émettre des conseils
Ok pour le rendre un peu plus clair, et surtout n'indiquer ce manque de
consens que sur la distribution et pas le transport.


>
> > je souhaiterais déplacer le point line/minor_line dans la partie réseaux
> de distribution,
> > parce que le réseau de transport doit être à 100% décrit avec power=line.
>
> avis perso, selon moi, dans la zone grise, le critère devrait être sur
> le voltage/utilisation. une ligne ne peux pas être à un endroit "majeur"
> et plus loin "mineur" simplement parce que localement le type de poteau
> change
> avis perso bis : pour moi l'utilité de minor_line c'est "à quoi
> sert la ligne qui passe dans tel rue ?" et "carte du réseau
> électrique transport <> distribution"
>
C'est un des axes mais pas le seul. Certains souhaitent juste faire la
distinction juste pour mettre un trait plus finsur le rendu.
Comme toi je pense qu'une ligne d'importance ne devient pas insignifiante
au milieu juste parce que les supports sont plus anciens ou plus petits.


Le 30 août 2017 à 11:45,  a écrit :

>
> Je reste encore trop franco-français, mais la limite à " inférieur à 50 kV
> " me semblais plus judicieux, puisque c'est la limite (en france) entre la
> HTA et la HTB selon le Décret 95-608 du 6 mai 1995.
>
Le but est de ne discuter que sur le cas Français pour commencer.
Il y a des limites partout, mais est-ce que celle entre la HTA et HTB est
la plus judicieuse à considérer ?


> Ensuite l'IEC 60038 parle de limite à 35 kV.
>
> D'où la question, avons-nous des équipement entre 35kv et 50 kV ? Si oui,
> c'est galère, sinon, on met la limite à 35 kV comme l'indique la norme
> internationale
>

Oui, il reste des lignes RTE, de transport donc, à 42 kV
Pire : certaines lignes RTE à 42kV ont été rétrocédées à la distribution en
20kV comme ici : http://www.openstreetmap.org/way/517446289
https://www.google.fr/maps/@45.3481164,6.3074121,3a,21.5y,340.6h,100.36t/data=!3m7!1e1!3m5!1sIerETOKiRD99vjFtuXGdNw!2e0!6s%2F%2Fgeo3.ggpht.com%2Fcbk%3Fpanoid%3DIerETOKiRD99vjFtuXGdNw%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D77.04886%26pitch%3D0%26thumbfov%3D100!7i13312!8i6656
Visuellement ce serait une power=line, mais dans l'exploitation une
prétendue "minor".

Descendre la limite entre HTA (20/15 kV) et BT (400V) ne laisse plus de
place à l'hésitation
Je ne connais pas le cas de lignes HT converties à la BT, ni l'inverse
d'ailleurs

Et surtout penser à ces cas là :
https://www.google.fr/maps/@45.9888313,6.1386526,3a,75y,300.72h,101.13t/data=!3m6!1e1!3m4!1swv2jJXgYcuHTN9XnK_rmfQ!2e0!7i13312!8i6656
Sur le même poteau on a:
- Extrémité de ligne 20 kV
- Interrupteur BT
- Extrémités de lignes BT
- Transition aéro-souterraine BT (qui ne concerne d'aucune sorte le 20 000
V)

Pouvoir signifier que c'est la transition et l'interrupteur sont sur la BT
via minor_line serait une grosse avancée

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

Re: [OSM-talk-fr] Présentation OSM et cartopartie avec CD63 et Comcom Billom

2017-09-07 Thread François Lacombe

Bonsoir Nicolas,

Le 7 septembre 2017 à 16:48, Nicolas Dumoulin  a
écrit :

>
>  - une proposition des POI et attributs les plus pertinents vis-à-vis des
> centres d'intérêt du projet : mobilité, patrimoine (Label pays d'art et
> d'histoire), culture et loisirs
>

Au risque d’être l'original de l'étape, ne pas oublier les trucs qui font
de la fumée et des étincelles, comme les transfos électriques, les
pipelines, les bornes à incendie, les réservoirs d'eau, les armoires de rue.

Quoi que tu as raison, je le classe dans "culture et loisirs" ;)


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

[OSM-talk-fr] Nouvelle modélisation des transformateurs électriques

2017-09-07 Thread François Lacombe

Bonjour à tous,

Cette été a été l'occasion de produire une nouvelle étape dans la carto des
réseaux électriques et de leur fonctionnement.
La proposition est en cours de vote sur le wiki et une annonce a été
envoyée sur la ML internationale, que je reporte ici pour les francophones
(même si la propal est en anglais)

https://wiki.openstreetmap.org/wiki/Proposed_features/Transformer_extension_proposal

C'est certes très technique, le but est de décrire l'architecture et
fonctions de beaucoup de transformateurs électriques différents. Ce sont
des appareils chargés de modifier la tension du courant électrique dans le
réseau.

Tout le monde est invité à regarder la cohérence et définition des tags,
avec ou sans approche technique. Rendez-vous ensuite au bas de la page dans
la section Voting.

Merci par avance pour votre contribution


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

Re: [OSM-talk-fr] Nouvelle modélisation des transformateurs électriques

2017-09-28 Thread François Lacombe

Hello,

La proposition indiquée début septembre a été acceptée sur le wiki, à
l'issue d'un vote de 15 jours terminé la semaine dernière.
https://wiki.openstreetmap.org/wiki/Proposed_features/Transformer_extension_proposal#Post-vote_cleanup

Les pages du wiki concernées ont été mises à jour, et traduites en Français
autant que faire se pouvait.
https://wiki.openstreetmap.org/wiki/FR:Tag:power%3Dtransformer
https://wiki.openstreetmap.org/wiki/FR:Key:windings

Bien que sujet très technique, la nouvelle modélisation sert autant la
description des réseaux publics d'électricité et le ferroviaire électrifié.
La connaissance des transfos permet de mieux comprendre le fonctionnement
des réseaux et des enjeux autour de leur développement.

Il y a beaucoup de valeurs qui pourraient etre simplement présentes dans
une base de données métier dédiée et liée à OSM avec une ref=*, mais elle
n'existe pas.
Il est bien question ici d'une collecte de terrain responsable (dans le
respect de la securité des personnes et des biens) dans l'attente de
l'opendata, un jour. Le modèle est là pour servir cette collecte de terrain
lorsqu'elle est possible, pour regrouper l'info de manière cohérente.
Pour info, la puissance statique d'un transfo n'est ni une puissance
souscrite ni un transit effectif et n'est donc pas couvert par le secret
des affaires.

A votre dispo pour les questions et différents cas bizarres que vous
pourrez trouver

François

Le 7 septembre 2017 à 09:20, François Lacombe <fl.infosrese...@gmail.com> a
écrit :

> Bonjour à tous,
>
> Cette été a été l'occasion de produire une nouvelle étape dans la carto
> des réseaux électriques et de leur fonctionnement.
> La proposition est en cours de vote sur le wiki et une annonce a été
> envoyée sur la ML internationale, que je reporte ici pour les francophones
> (même si la propal est en anglais)
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/
> Transformer_extension_proposal
>
> C'est certes très technique, le but est de décrire l'architecture et
> fonctions de beaucoup de transformateurs électriques différents. Ce sont
> des appareils chargés de modifier la tension du courant électrique dans le
> réseau.
>
> Tout le monde est invité à regarder la cohérence et définition des tags,
> avec ou sans approche technique. Rendez-vous ensuite au bas de la page dans
> la section Voting.
>
> Merci par avance pour votre contribution
>
>
> François
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Bornes à incendie : votez sur la 1ere proposition

2017-10-01 Thread François Lacombe

Bonsoir à tous,

Suite à la séparation en plusieurs morceaux de la proposition sur les
bornes à incendie, le premier volet est ouvert au vote.
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Fire_Hydrant_Extensions

C'est une évolution plutôt ambitieuse qui est proposée.
Même si un grand nombre d'objets vont devoir être revus, le nouveau
formalisme apporte certains avantages
Il y a une confusion entre les types de bornes et la source de l'eau. Il
est proposé d'utiliser un tag pour le type physique et un autre pour la
source
Enfin, le namespace fire_hydrant: n'était pas nécessaire pour un certain
nombre de clés, il est proposé d'utiliser d'autres clés plus universelles à
la place pour plus de lisibilité

Le vote est ouvert jusqu'au 15/10, bonne soirée

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

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

Le 23 août 2017 à 23:29, marc marc  a écrit :

>
> oui, comme je disais : vas-y ! ou attends tu l'avis Bhynoteam ?
>
C'est envoyé :
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Fire_Hydrant_Extensions#Flow_and_pipes_capacity

Yann Kacenelen m'a répondu sur Twitter avec ce document qu'il avait rédigé
en 2015
https://framagit.org/ykacenelen/point_eau_incendie_OSM/snippets/655

Il y a certains points en commun avec la proposition... d'autres un peu
moins.


> et c'est là que emporté par le mouvement, tu vas rajouter une modif du
> tag pression parce que lui aussi n’aucune raison d'être préfixé.
> pressure sur une borne, c'est aussi précis que fire_hydrant:pressure
>

+1 Il faudrait que j'ajoute également un sujet sur la suppression des
namespaces.

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

Re: [OSRM-talk] Use OSRM on rivers, railways, power lines

Hi Daniel, Ricardo,

Thank you for your answers.

I completely agree on necessity of perfect connectivity between features.
It has been a concern for me regarding power networks for years of
contribution now.

The challenge is currently to adapt car profile to power lines
Voltage may act as the maxspeed key, and transformers as toll

As you may see in the relation example I gave, there is two substations at
the ends of line members.
Differently from roads or rivers, you can't connect to power lines or
pipelines anywhere. Start and end into substations is mandatory
(power=substation or pipeline=substation, they are both areas)
How can I told osrm to look for the nearest substation before starting
routing in the graph exclusively composed of power lines or pipelines ?

Guidance information isn't so relevant in such networks, then I will only
focus on osrm path answer

François

*François Lacombe*

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

2017-08-24 18:52 GMT+02:00 Ricardo Pereira <ricardo.pere...@gmail.com>:

> We use OSRM to route within water only (Oceans and Rivers). It makes
> absolute no difference what you are routing through as long as you can
> provide a mesh with your topology.
> Our Lua script therefore matches the tags that we create for own data,
> nothing to do with OSM.
>
> Cheers
>
> On Thu, 24 Aug 2017 at 16:15 François Lacombe <fl.infosrese...@gmail.com>
> wrote:
>
>> Hi all,
>>
>> Since there is not only roads but many other topological networks mapped
>> on OSM, I'm wondering how osrm may be usable on them.
>>
>> Example : a power route used to establish a link between two substations
>> http://www.openstreetmap.org/relation/6694740
>>
>> I know pretty well how lua profiles are built, for cars, bike,
>> pedestrian... but is there any profile available for power or gas pipelines?
>> Let's say we have proper data, is the profile the only thing to change to
>> use osrm on pipelines or rivers exclusively ?
>>
>> Many thanks for any answer regarding this question
>>
>>
>> François
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[OSM-talk-fr] StreetComplete et les poteaux électriques

Bonsoir à tous,

Une petite info que je viens de voir passer
StreetComplete a ajouté une quête questionnant l'utilisateur sur le
matériau constituant les poteaux électriques environnants.
https://github.com/westnordost/StreetComplete/pull/493

La nouvelle version n'est pas encore publiée, encore un peu de patience.

Comme pour les routes avec la clé surface, le tag material sur les supports
de réseau a une grande valeur.
Un croisement avec des landuse=forest permet assez facilement de repérer
les tronçons les plus sensibles aux chutes d'arbre (ou au feu, comme ces
dernières semaines) avec une faible résistance. Ainsi je connais déjà
quelques entreprises qui surveillent l'élagage et le risque feu avec notre
carto.

J'en ai profité pour traduire un peu mieux la version anglaise de
power=pole qui présente moult détails
https://wiki.openstreetmap.org/wiki/FR:Tag:power%3Dpole

Bonne soirée


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

Re: [OSRM-talk] Use OSRM on rivers, railways, power lines

2017-08-24 23:18 GMT+02:00 Daniel Patterson :

> Franccois,
>
>   In the lua profiles, you can set the `result.is_startpoint` property in
> `process_way` (used to be `way_function`) to determine whether you can snap
> to them.  We currently use this for ferry routes - paths can use them, but
> can't start/end on them.
>
>   Set `is_startpoint` to true for your substations way areas, and
> `is_startpoint` to false for the transmission lines.
>

That's exactly what I need, thank you


>   The route will start by following the outside edge of the substations
> area polygon, but it sounds like that doesn't matter too much to you.
>

It doesn't matter indeed.
But it may be an issue that power lines aren't actually connected to
substation perimeter ?

Like this one : https://www.openstreetmap.org/way/100500802
The outside edge of the substation is the fence surrounding it and power
lines goes above it without connection.

Should I preprocess my data to make it more accessible to osrm or there's
other way ?

Francois
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

2017-08-21 Thread François Lacombe

Le 21 août 2017 à 10:58, marc marc  a écrit :

> il y a la dépréciation de type=pond sur laquelle j'aurais voulu éviter
> qu'on vote vu que cela conforte la séparation entre hydrant et suction.
>

Ok, en effet
Par contre si il n'est pas déprécié, il faudra quand même le passer dans
water_source plutôt que de le laisser dans le type d'hydrant


>
> Par contre pour ta proposition de réduire flow_capacity en capacity,
> je ne suis pas favorable. capacity est trop générique.
>
Sa généricité est un avantage en fait


> sans lire le wiki, cela pourrait tout aussi bien représenter le nombre
> de tuyaux qu'on peux connecter simultanément.
>
Sans lire la notice, on a généralement des problèmes
Cela dit, on a pas indiqué de clé où donner le nombre de connexions
possibles et la confusion peut en effet régner.
Là, un namespace peut etre utile et vu qu'il y a déjà des sous-clés de
capacity, que penses-tu de
capacity:flow et capacity:pipes ?


> De plus je pense qu'il est utile, pour les éditeurs, d'avoir un seul
> type d'unité par clé afin de pouvoir l'afficher lors de la saisie.
> sinon les éditeurs doivent avoir une liste hard-codée des unités en
> fonction de l'objet, c'est contre-productif à l'effet souhaité d'une
> harmonisation des clefs.
>
Problématique intéressante que je n'ai pas rencontré jusque là.
JOSM par exemple, n'affiche pas d'unité dans les presets il me semble ?

Est-ce que tu étend cela aux multiples ? Parce que pour height, même si le
défaut est en mètres, on peut préciser des valeurs en km en l'ajoutant à la
fin de la valeur.
Ainsi l'éditeur ne gère pas cette partie

capacity:flow réglera le problème de l'unité en tout cas si c'est ce qui
est retenu.


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

Re: [OSRM-talk] Use OSRM on rivers, railways, power lines

2017-08-28 Thread François Lacombe

Hi Daniel,

This is indeed an interesting point.

In substations, every incoming line is often connected to busbars, which
allow to switch power from lines to another.
They are supposed to be in OSM when outdoor and visible on aerial imagery
like this one : http://www.openstreetmap.org/way/170169821

Then I'd better to propagate substation attributes on its busbars and then
define them as is_starting=true
If I don't find them in OSM data, it's pretty easy to create a virtual one
by linking every incoming line end point.


Once the is_starting problem solved, can osrm understand directly route
relation like the one given in my first mail :
http://www.openstreetmap.org/relation/6694740
Or should I convert them in separate ways before building osrm network ?


All the best

François


*François Lacombe*

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

2017-08-25 18:04 GMT+02:00 Daniel Patterson <dan...@mapbox.com>:

> Hi François,
>
>   The only problem I can see is that OSRM only snaps to *edges*, not
> nodes, and the `is_startpoint` property is only available for ways, not
> nodes.
>
>   If you insert new artificial ways that connect the centroid to each line
> and have different tags and can be marked as `is_startpoint=true`, then it
> will work fine.  If you simply extend the powerlines by adding an
> additional noderef to the powerline ways, then you'll still have the
> nothing-to-snap-to problem.
>
> daniel
>
> On Thu, Aug 24, 2017 at 11:58 PM, François Lacombe <
> fl.infosrese...@gmail.com> wrote:
>
>> Hi Daniel,
>>
>> Ok,
>>
>> Or I can take the centroid of each substation area and connect each line
>> to it.
>> Then, drop the area and only keep substations nodes which get the
>> is_startpoint in the profile.
>>
>> On render side, I will surely be able to match substation nodes given by
>> osrm and actual areas with ref tags.
>>
>> I'll be testing it for some times and will share it if interested
>> Thank you for your time
>>
>>
>> All the best
>>
>>
>> 2017-08-25 0:04 GMT+02:00 Daniel Patterson <dan...@mapbox.com>:
>>
>>> Yes, connectivity will be a problem in that example.  If you make the
>>> lines `is_startpoint=false` and they're not connected to something else,
>>> then you won't be able to route over them.
>>>
>>> You will need to do some pre-processing here - create artificial nodes
>>> at the points where the substation boundaries cross the lines and connect
>>> both ways to those artificial nodes.
>>>
>>> daniel
>>>
>>> On Thu, Aug 24, 2017 at 2:33 PM, François Lacombe <
>>> fl.infosrese...@gmail.com> wrote:
>>>
>>>>
>>>> 2017-08-24 23:18 GMT+02:00 Daniel Patterson <dan...@mapbox.com>:
>>>>
>>>>> Franccois,
>>>>>
>>>>>   In the lua profiles, you can set the `result.is_startpoint` property
>>>>> in `process_way` (used to be `way_function`) to determine whether you can
>>>>> snap to them.  We currently use this for ferry routes - paths can use 
>>>>> them,
>>>>> but can't start/end on them.
>>>>>
>>>>>   Set `is_startpoint` to true for your substations way areas, and
>>>>> `is_startpoint` to false for the transmission lines.
>>>>>
>>>>
>>>> That's exactly what I need, thank you
>>>>
>>>>
>>>>>   The route will start by following the outside edge of the
>>>>> substations area polygon, but it sounds like that doesn't matter too much
>>>>> to you.
>>>>>
>>>>
>>>> It doesn't matter indeed.
>>>> But it may be an issue that power lines aren't actually connected to
>>>> substation perimeter ?
>>>>
>>>> Like this one : https://www.openstreetmap.org/way/100500802
>>>> The outside edge of the substation is the fence surrounding it and
>>>> power lines goes above it without connection.
>>>>
>>>> Should I preprocess my data to make it more accessible to osrm or
>>>> there's other way ?
>>>>
>>>> Francois
>>>>
>>>>
>>>> ___
>>>> OSRM-talk mailing list
>>>> OSRM-talk@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>>>
>>>>
>>>
>>> ___
>>> OSRM-talk mailing list
>>> OSRM-talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>>
>>>
>>
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>
>>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

2017-08-28 Thread François Lacombe

Hello,

Viking émet l'idée intéressante que les usages de capacity:* donnent des
volumes statiques (des places de parking, de banc, ...) et qu'il faudrait
plutôt adopter une clé qui donne un volume variable dans le temps (des
m3/s, m3/h, l/min...).

Ainsi je pense à la clé rating=* qui est utilisée pour l'instant sur les
transfos électriques, pour donner la quantité d'énergie qui peut les
traverser.
Vu qu'une proposition est en cours sur les transfos électriques, et que la
clé rating est utilisée moins de 10 000 fois, il serait plus ou moins
facile de la remplacer par rating:intensity. Nous pourrions introduire
ensuite rating:water pour tout ce qui fait transiter de l'eau.

Ca donnerait deux clés bien génériques, capacity pour les volumes (il
faudra penser à éviter volume=* pour les cuves de fluides du coup) et
rating=* pour les flux.


J'attends son retour sur cette proposition

François

*François Lacombe*

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

Le 24 août 2017 à 11:54, François Lacombe <fl.infosrese...@gmail.com> a
écrit :

>
> Le 23 août 2017 à 23:29, marc marc <marc_marc_...@hotmail.com> a écrit :
>
>>
>> oui, comme je disais : vas-y ! ou attends tu l'avis Bhynoteam ?
>>
> C'est envoyé : https://wiki.openstreetmap.org/wiki/Talk:Proposed_
> features/Fire_Hydrant_Extensions#Flow_and_pipes_capacity
>
> Yann Kacenelen m'a répondu sur Twitter avec ce document qu'il avait rédigé
> en 2015
> https://framagit.org/ykacenelen/point_eau_incendie_OSM/snippets/655
>
> Il y a certains points en commun avec la proposition... d'autres un peu
> moins.
>
>
>> et c'est là que emporté par le mouvement, tu vas rajouter une modif du
>> tag pression parce que lui aussi n’aucune raison d'être préfixé.
>> pressure sur une borne, c'est aussi précis que fire_hydrant:pressure
>>
>
> +1 Il faudrait que j'ajoute également un sujet sur la suppression des
> namespaces.
>
> François
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] relation network <> tags network