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

[François Lacombe]

Bonsoir,

Le 4 septembre 2017 à 11:12, marc marc  a écrit :

> résumé de la mailing anglaise :
> - quasi toutes les valeurs communes
>
Entends-tu que toutes les clés sont "universalisées", au lieu d'utiliser
fire_hydrant: ou suction_point: ?
C'est une très bonne chose ce point en tout cas :)


> Le 01. 09. 17 à 12:08, François Lacombe a écrit :
> honnêtement, j'ai déjà encodé beaucoup de borne dans osm mais
> je suis incapable de déterminer si la connexion est petite ou non.
>

Le principe n'était pas de fixer des plages de diamètres comme petit ou
grand.
Le fait est que sur une borne donnée, il y a des grandes connexions et des
petites connexions. Un même diamètre pourra être petit sur l'une et grand
sur l'autre.

Le but est d'éviter impérieusement les listes à ;


> tout ce que je peux donner comme avis, c'est par rapport
> aux autres que j'ai déjà vu.
> est-ce que cette information est utile et à qui ?
> un pompier va-t-il faire un choix là-dessus ?
> ou "chargé d'inventaire" ?
>

Oui : les lances à incendie ont des diamètres précis. Comme les pompes,
c'est une question de compatibilité du matériel embarqué au départ.



> c'est un peu pour la même raison que je n'encode pas le chiffre que
> je vois parfois sur le connecteur.est-ce le diamètre du couplage ?
>

Sur le connecteur, peut-être.
Si tu vois des "DN40", "DN100" marqués sur la borne, c'est le diamètre de
la connexion au réseau sous le trottoir.


> probablement. est-ce que cela une utilité ou vaut mieux passer
> le même temps en encodant plus de borne ?
>
Les deux ne sont pas incompatibles. L'objet n'est pas de préciser tous les
tags en un seul coup. Le problème est surtout de structurer l'information
quand celle-ci est disponible.
Il faut toujours lire les proposition de tag comme "si jamais vous avez
cette info, c'est comme ca qu'il faut l'indiquer".


> j'ai l'impression que cela ne sert qu’éventuellement au pompier au
> moment de brancher son tuyau s'il a un doute en jetant un coup d’œil.
> Et encore, sans doute seulement au pompier débutant.
>

Où à une IA qui décide quel camion tu prends (parce que t'as pas le temps
de réfléchir à ce moment là), connaissant le matériel à l'intérieur.


> pour la fabriquant/modèle, rien n’empêche de rajouter cela en "tag
> utile" sur la page mondiale et le détail sur la page francophone
>

Il ne faut surtout pas créer de nouvelle clé pour cela, sachant que ca
existe déjà.
Évidemment que c'est optionnel.



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

[marc marc]

résumé de la mailing anglaise :
- quasi toutes les valeurs communes

Le 01. 09. 17 à 12:08, François Lacombe a écrit :
> j'ai proposé d'avoir des couplings:small
honnêtement, j'ai déjà encodé beaucoup de borne dans osm mais
je suis incapable de déterminer si la connexion est petite ou non.
tout ce que je peux donner comme avis, c'est par rapport
aux autres que j'ai déjà vu.
est-ce que cette information est utile et à qui ?
un pompier va-t-il faire un choix là-dessus ?
ou "chargé d'inventaire" ?
c'est un peu pour la même raison que je n'encode pas le chiffre que
je vois parfois sur le connecteur.est-ce le diamètre du couplage ? 
probablement. est-ce que cela une utilité ou vaut mieux passer
le même temps en encodant plus de borne ?
j'ai l'impression que cela ne sert qu’éventuellement au pompier au 
moment de brancher son tuyau s'il a un doute en jetant un coup d’œil.
Et encore, sans doute seulement au pompier débutant.

pour la fabriquant/modèle, rien n’empêche de rajouter cela en "tag 
utile" sur la page mondiale et le détail sur la page francophone

> Il y a normalement l'équipe d'OsmHydrant qui est prévenue et qui devrait 
> aussi donner son avis avant le vote, pour éviter toute déconvenue

heureusement qu'il n'y a pas le feu :)

___
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

[François Lacombe]

Hello,

Petit point d'étape sur les récentes discussions avec Viking
On avance : la plupart des clés ont perdu leur prefixe fire_hydrant: ou
suction_point.

Autre sujet maintenant :
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Fire_Hydrant_
Extensions#Flow_and_pipes_capacity

Je trouvais les tags couplings_type et couplings_diameter un peu
restrictifs pour décrire quelque chose d'aussi divers et détaillé que les
connexions des bornes. Surtout que c'était avec des valeurs listes
Ainsi j'ai proposé d'avoir des couplings:small, couplings:medium ou
couplings:big ou ne serait-ce que couplings=x pour donner le nombre de
connexions possibles.
C'est pas le meilleur schéma possible, mais les listes à ; sont à bannir,
avec ou sans unités.
Pour l'instant la réponse est non, convaincu qu'il faut éviter à tout prix
les namespaces (ce qui n'était pas tout à fait mon propos avec
fire_hydrant:)

Il y a normalement l'équipe d'OsmHydrant qui est prévenue et qui devrait
aussi donner son avis avant le vote, pour éviter toute déconvenue

Chose également étrange, il serait aussi de nouveau question de fusionner
fire_hydrant et suction_point d'après le dernier mail recu sur la ML
internationale.

Il reste encore un peu de chemin avant d'obtenir un truc votable, sur la
forme discussion vraiment intéressante et constructive, c'est encourageant



*François*
Le 30 août 2017 à 11:28, François Lacombe  a
écrit :

>
> 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] Bornes à incendie : proposition en cours d'écriture

[François Lacombe]

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] Bornes à incendie : proposition en cours d'écriture

[marc marc]

Le 28. 08. 17 à 08:39, François Lacombe a écrit :

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

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,

 > 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 ?
___
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

[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 

Le 24 août 2017 à 11:54, François Lacombe  a
écrit :

>
> 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: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[François Lacombe]

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: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[marc marc]

Le 23. 08. 17 à 00:32, François Lacombe a écrit :
> 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.
oui, comme je disais : vas-y ! ou attends tu l'avis Bhynoteam ?

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

osm.sanspourriel at spamgourmet.com a écrit :
 > capacity:flow me va. Préciser l'unité par défaut.
pour ma part, j'avais déjà commencé a encoder sans unité=m3/h
la proposition ne parle pas de mettre le m3/h en 1er (il est apparemment 
américain) mais précise heureusement de mettre l'unité.
sauf qu'il considère l'unité obligatoire, c'est une petite régression, 
n'hésites pas à lui répondre si tu veux, histoire d'avoir une diversité 
d'intervenant
https://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant_Extensions
https://lists.openstreetmap.org/pipermail/tagging/2017-August/033080.html
___
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

[François Lacombe]

Le 23 août 2017 à 00:12, marc marc  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] Bornes à incendie : proposition en cours d'écriture

[marc marc]

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

> 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 ?
mais si tu penses qu'il faut rajouter les capacités de connexion pour 
faire passer par cohérence les capacités de débit, vas-y
___
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

[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

[marc marc]

> Le 21 août 2017 à 23:23, marc marc  a écrit :
> 
> capacity:flow je trouve flow assez générique.
Je voulais l'inverse : tellement spécifique que flow n'existerait pas avec une 
autre clef
___
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

[marc marc]

Le 21. 08. 17 à 21:10, François Lacombe a écrit :
> 
> Le 21 août 2017 à 19:27, marc marc  > a écrit :
> 
>  > Bnhynoteam
> c'est quoi/qui ?
> 
> 
> La Base des Hydrants nationale ouverte ;)
si tu les connais, préviens les qu'ils ne réagissent pas ici.

> flow_capacity existe déjà. 6000+ occurrences.
> Lui faire perdre son préfixe pour le rendre commun aux suction_point
> serait déjà une avancé.
> Depuis le temps que + de 80% de la proposition est accepté unanimement,
> je pense qu'à un moment, il vaut mieux valider ce qui est unanime quitte
> à ouvrir un nouveau chantier pour le reste.
> C'est un piège.
> Si on laise flow_capacity, le coup d'après il sera à 80k utilisations et 
> indéboulonnable (parce qu'indiqué comme Approved dans le wiki entre autres)
> Je ne dis pas que c'est une mauvaise chose, mais il faut choisir en 
> ayant ça à l'esprit.
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.


> c'est en ce sens que je n'ai pas réagit à propos de fire_hydrant:count
> c'est obscur, y compris la description du wiki.
> mais comme la propal n'y touche pas, je préférais ne pas ouvrir un point
> supplémentaire de discussion afin que le reste soie validé.
> count, c'est comme type, le fourre-tout qu'on peut rendre plus explicite 
> dans 80% des cas.
> Au contraire, il faut en parler.
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.


> 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

___
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

[osm . sanspourriel]

Clairement capacity c'est sans unité ou une unité évidente (chambres, 
place de camping, parking).


Et pour la question des unités, soit c'est une unité directe du SI soit 
on doit la préciser.


Par exemple mph pour les vitesses car on utilise en général des 
multiples de 5 et souvent de 10.
On voit mal l'éditeur transformer en 72,4 km/h en base. Mais un 
calculateur d'itinéraire va tout convertir en valeurs numériques.

Par contre 100 cm devient 1 (m).

capacity:flow me va. Préciser l'unité par défaut.

Le 21/08/2017 à 21:10, François Lacombe - fl.infosrese...@gmail.com a 
écrit :
capacity est déjà un concept largement utilisé, que l'on peut 
compléter en lui ajoutant des suffixes pour gérer le cas des unités.
C'est ce que je trouve intéressant, mais conçoit que ça ne séduise pas 
tout le monde.
En le choisissant, on se range du côté de l'existant et ce sera ainsi 
plus facile à faire adopter.


___
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

[François Lacombe]

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

>   > Bnhynoteam
> c'est quoi/qui ?
>

La Base des Hydrants nationale ouverte ;)
Un idée d'Eric Pommereau, Yann Kacenelen, Donat Robaux et d'autres
On peut en trouver trace sur Twitter, et j'ai mis un n en trop. C'est
Bhynoteam le bon nom


> j'ai répondu en ce sens ce midi sur la ml mondiale avec une phrase de
> remplacement qui ne ferme pas la porte à une fusion des 2 tag emergency.
> A voir ce qu'il en pense.
>
Et je partage complètement
Il faut juste indiquer water_source=pond pour le moment et c'est très bien.


>
> > Par contre pour ta proposition de réduire flow_capacity en capacity,
> > je ne suis pas favorable. capacity est trop générique.
> > 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
> tu ne peux pas espérer que ceux qui utilisent id ou un éditeur mobile
> commencent par lire le wiki pour chaque tag utilisé.
>
Non en effet, mais les presets en tiennent compte et donc les éditeurs
donnent des conseils voire des avertissements en cas de contributions
identifiée comme maladroite.


> Je trouve que le nom d'un tag doit vraiment être très parlant.
>
Nous sommes d'accord. Néanmoins c'est une approche subjective. Ce qui est
parlant pour l'un ne l'est pas pour l'autre. Regardes comment certains
s’accommodent des clés fire_hydrant:xx

les preset pour les clefs ayant une liste de valeur courante.
> le wiki étant là pour la qualité des détails ou des explications.
>
Non c'est la seule référence, c'est pour ça que la rédaction des pages doit
être la plus complète possible en recensant tous les cas si possible.

flow_capacity existe déjà. 6000+ occurrences.
> Lui faire perdre son préfixe pour le rendre commun aux suction_point
> serait déjà une avancé.
> Depuis le temps que + de 80% de la proposition est accepté unanimement,
> je pense qu'à un moment, il vaut mieux valider ce qui est unanime quitte
> à ouvrir un nouveau chantier pour le reste.
>
C'est un piège.
On a eu le cas sur l'énergie et il y a des choses qui ne se feront jamais
(sur les supports poteaux et pylônes, qu'on aurait pu rapprocher de
man_made=tower)
En effet le périmètre de la proposition doit rester raisonnable, mais
d'expérience je ne suis pas d'accord pour faire la moitié du chemin
maintenant le reste après.
Si on laise flow_capacity, le coup d'après il sera à 80k utilisations et
indéboulonnable (parce qu'indiqué comme Approved dans le wiki entre autres)
Je ne dis pas que c'est une mauvaise chose, mais il faut choisir en ayant
ça à l'esprit.

capacity est déjà un concept largement utilisé, que l'on peut compléter en
lui ajoutant des suffixes pour gérer le cas des unités.
C'est ce que je trouve intéressant, mais conçoit que ça ne séduise pas tout
le monde.
En le choisissant, on se range du côté de l'existant et ce sera ainsi plus
facile à faire adopter.


> c'est en ce sens que je n'ai pas réagit à propos de fire_hydrant:count
> c'est obscur, y compris la description du wiki.
>
mais comme la propal n'y touche pas, je préférais ne pas ouvrir un point
> supplémentaire de discussion afin que le reste soie validé.
>
count, c'est comme type, le fourre-tout qu'on peut rendre plus explicite
dans 80% des cas.
Au contraire, il faut en parler.
Ne pas discuter des points pour accélérer ne m'attire pas trop.

> 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 ?
> Je n'en ai jamais vu mais ce serrait utile. Rien ne bloque techniquement
>
> > Est-ce que tu étend cela aux multiples ? Parce que pour height, même si
> Mais à nouveau je pense que c'est un tout autre sujet, qui ne doit pas
> bloquer la validation de la proposition actuelle.
>
Ok, je partage.
On va trouver une clé adéquate pour indiquer un débit et ce sera réglé.

Accordons-nous sur ces points, et nous verrons ce qu'il est utile de lancer
dans le Talk de la propal ensuite

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

[marc marc]

François Lacombe a écrit :

 > Bnhynoteam
c'est quoi/qui ?

> 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
j'ai répondu en ce sens ce midi sur la ml mondiale avec une phrase de 
remplacement qui ne ferme pas la porte à une fusion des 2 tag emergency.
A voir ce qu'il en pense.

> Par contre pour ta proposition de réduire flow_capacity en capacity,
> je ne suis pas favorable. capacity est trop générique.
> 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
tu ne peux pas espérer que ceux qui utilisent id ou un éditeur mobile 
commencent par lire le wiki pour chaque tag utilisé.
Je trouve que le nom d'un tag doit vraiment être très parlant.
les preset pour les clefs ayant une liste de valeur courante.
le wiki étant là pour la qualité des détails ou des explications.

> 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 ?

flow_capacity existe déjà. 6000+ occurrences.
Lui faire perdre son préfixe pour le rendre commun aux suction_point 
serait déjà une avancé.
Depuis le temps que + de 80% de la proposition est accepté unanimement, 
je pense qu'à un moment, il vaut mieux valider ce qui est unanime quitte 
à ouvrir un nouveau chantier pour le reste.
c'est en ce sens que je n'ai pas réagit à propos de fire_hydrant:count
c'est obscur, y compris la description du wiki.
mais comme la propal n'y touche pas, je préférais ne pas ouvrir un point 
supplémentaire de discussion afin que le reste soie validé.

> 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 ?
Je n'en ai jamais vu mais ce serrait utile. Rien ne bloque techniquement

> 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.
Si je devais coder un éditeur, je ferrai une différence entre ce que 
l'utilisateur encode et ce qui est mis en base.
une largeur encodée comme 100cm serrait transformé par 1 en base.
J'avais fais la réflexion lorsqu'il a mis l/min devant m3/h.
Mais à nouveau je pense que c'est un tout autre sujet, qui ne doit pas 
bloquer la validation de la proposition actuelle.
___
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

[Christian Quest]

Le 21/08/2017 à 12:44, François Lacombe a écrit :


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

capacity=* est utilisé pour dénombrer, souvent pour un nombre de places 
(places de stationnement, sièges dans une salle de spectacle, etc)... 
pour des m3/mn ça me semble bien peu cohérent.




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 ?


ça me semblerait bien mieux

--
Christian Quest - OpenStreetMap France

___
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

[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: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

[marc marc]

Le 21. 08. 17 à 07:57, François Lacombe a écrit :
> 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 ?
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.

Par contre pour ta proposition de réduire flow_capacity en capacity,
je ne suis pas favorable. capacity est trop générique.
sans lire le wiki, cela pourrait tout aussi bien représenter le nombre 
de tuyaux qu'on peux connecter simultanément.
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.
___
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

[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

[marc marc]

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