Re: [OSM-talk-fr] Borne de puisage

2018-10-29 Par sujet Philippe Verdy 
Si la couleur n'est pas réglementée, alors autant l'indiquer explicitement
par un tag "color=green/blue/yellow" voire meme "red" si le rouge n'est pas
réservée aux seuls pompiers qui doivent avoir leur propre marquage et clés
d'accès avec la vanne qui va bien pour eux. D'ailleurs je ne suis convaincu
que tous les hydrants incendie soient toujours rouges

Le lun. 29 oct. 2018 à 11:52, Nicolas Moyroud  a écrit :

> Merci Vincent (l'autre !) pour ces précisions.
>
> > Tu en as de ces TOCs toi ;)
> Oui tout plein, mais j'ai même pas envie de me faire soigner !
> > Certaines communes ne respectent pas ce code couleur. Je pense par
> > exemple à Senlis (60) où une bonne proportion des "vrais" poteaux
> > incendie sont du même vert que les bornes de puisage, juste pour une
> > raison esthétique :
> MDR. Pour des raisons esthétiques c'est un peu comme tagguer pour le
> rendu ça ! D'après mon contact la réglementation devrait bientôt obliger
> à respecter les codes par catégories d'hydrant. A voir...
> > pour les jaunes (je n'en ai jamais vues sauf à... Disneyland Paris :)
> > ) je suppose qu'une valeur numérique pour ce même tag doit aller. Voir
> > https://taginfo.openstreetmap.org/keys/fire_hydrant%3Apressure.
>
> Pour les jaunes pas forcément évident de connaître la pression si ce
> n'est pas indiqué dessus (mais peut-être que ça l'est
> systématiquement?). Y'a moyen d'indiquer "supérieur à" pour une valeur
> numérique ? J'ai jamais fait ça...
>
> On dirait que Disneyland aime mettre la pression. :-P
>
> 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] opening_hours contre les parcs parisiens

2018-10-29 Par sujet Megan Parat 
On 10/26/18 2:28 PM, Philippe Verdy wrote:

> Le jeu. 25 oct. 2018 à 16:45, Francois Gouget  > a écrit :
>
> On Thu, 25 Oct 2018, Megan Parat wrote:
> [...]
>
> > 08:00-17:45; PH,Sa,Su 08:00-09:00 off, Mar 01-Mar Su[-1]
> 17:45-19:00,
> > Oct 01-Oct Su[-1] 17:45-19:30, Mar Su[-1]-Apr 30,Sep
> 17:45-20:30, May
> > 01-Aug 31 17:45-21:30
>
> [...]
>
> Là où la page opening_hours laisse penser que la virgule ne peut être
> utilisée que dans les listes (d'années, de mois ou d'heures), la
> spécification complète indique qu'on peut l'utiliser partout où on
> peut
> utiliser le point-virgule :
>
> |  opening_hours = 
> |  :  { 
>  }
> |  any_rule_separator: ';' | ',' | '||'
>
>
> Pas tout à fait :
> * le point-virgule dans un attribut indique une liste non-ordonnée
> (dont les éléments peuvent être librement permutés sans changement
> d'interprétation) : c'est valable normalement pour tout attribut OSM.
> * alors que la virgule impose un ordre de priorité.
>
> De fait les éléments séparés par point-virgules doivent être
> indépendants (ne pas se recouvrir, ou bien être équivalents
> sémantiquement)
>
> Ce qui n'est pas le cas dans l'exemple ici car le premier élément de
> la liste séparée par point-virgule "08:00-17:45" couvre une bonne
> partie du second (qui indique des horaires différents pour certaines
> dates).
>
> Il ne devrait donc pas y avoir de point-virgule du tout dans ton
> exemple, où la virgule dans un liste vient ajouter des éléments
> (ajouter des plages horaires, ou en retirer avec "off")  à la liste en
> modifiant les précédents.

L'ordre a une importance en général :

La spécification explique que la syntaxe générale d'opening_hours est
une liste de sélecteurs séparés par des points-virgules. Les horaires
retenus pour une date correspondent au *dernier* sélecteur valide. (cf.
explication pour time_domain sur la page
https://wiki.openstreetmap.org/wiki/FR:opening_hours/specification)

L'intérêt de la virgule est de pouvoir écrire par exemple '08:00-18:00,
Fr 20:00-24:00'. Avec une virgule, pour le vendredi, c'est ouvert de 8h
à 18h, puis de 20h à minuit. Avec un point-virgule, c'est ouvert
seulement de 20h à minuit car la deuxième règle est valable pour ce
jour, et ainsi prend précédence. (cf. explication de
additional_rule_separator §1)

> La syntaxe utilisée ci-dessus est en fait ambiguë puisque la partie
> séparée par des virgules (une fois le point-virgule converti en
> virgule) contient les éléments suivants, qui doivent être lus dans
> l'ordre, chaque élément modifiant le calendrier:
> - au départ (liste vide), par défaut tout est fermé, tous les jours
> quelque soit l'heure
> - "08:00-17:45" : ajoute l'ouverture tous les jours à cette plage
> horaire (cela remplace la fermeture
Correct pour le moment.
> - "PH" : n'indique aucune plage horaire, donc veut dire que cela
> ajoute l'ouverture toute la journée (24/24) des jours fériés
> - "Sa" : n'indique aucune plage horaire, donc veut dire  que cela
> ajoute l'ouverture toute la journée (24/24) de tous les samedis
> (fériés ou pas)
> - "Su 08:00-09:00 off" : exclue de tout ce qui précède l'ouverture de
> 8h à 9h si c'est un dimanche (donc le dimanche reste ouvert 23h sur 24
> si c'est férié, sinon ouvert seulement de 9h à 17h45)

La virgule est aussi utilisée pour les énumérations d'années, mois,
jours de la semaines, etc... (eg. 'Mo,We,Fr 08:00-18:00'). (cf. les
définitions de weekday_sequence, monthday_selector et year_selector)

Normalement, cette règle devrait prendre précédence sur les précédentes
si elle s'applique. Ça n'a pas trop de sens car c'est fermé par défaut.
C'est pour ça que si la règle définit une fermeture, celle ci se content
de supprimer la plage horaire. Donc pour '08:00-18:00; Mo 08:00-12:00
off', c'est ouvert le Lundi de midi à 18h. (cf. l'explication de
 (closed) )

C'est pour ça qu'il y a un point-virgule et non une virgule. Car le
comportement est le même et l'outil d'évaluation préfère le premier (car
il est moins complexe je suppose).

> - "Mar 01-Mar Su[-1] 17:45-19:00 : ajoute l'ouverte à cette plage
> horaire tous les jours de entre le 1er du mois de mars et le dernier
> dimanche de mars (n'a pas d'effet sur les dimanches fériée de mars,
> mais les autres dimanches non fériés de mars ont une ouverture allongée)
> - etc. (autres plages horaires ajoutées pour d'autres dates)
>
Elle s'applique pour les dimanches fériés car c'est la dernière qui
correspond et on utilise des virgules.
> Cette liste ne peut pas être librement permutée (notamment entre les
> éléments contenant des "off" et ceux qui sont "on" par défaut), mais
> peut être permutée entre deux éléments "on" s'il n'y a aucun élément
> "off" entre les deux.
>
> Et c'est le cas ici car tous les éléments sont "on" (par défaut), SAUF
> le 4e (Su 08:00-09:00) qui est "off".
>
> Hors je ne pense pas que ce soit ce que tu voulais (pas convaincu que
> tu voulais mettre des

Re: [OSM-talk-fr] Migrer les amenity=swimming_pool (le retour)

2018-10-29 Par sujet Noémie Lehuby 

Hello,

J'ai fait une passe sur les amenity=swimming_pool (ainsi que les 
leisure=swimming_pool) avec phone, website et wikidata.
J'ai aussi essayé opening_hours mais ce n'est pas assez discriminant, il 
y avait beaucoup de faux positifs (où le bassin et la piscine sont 
présents tous les deux, tous deux avec les tags opening_hours, pas 
toujours avec les mêmes valeurs d'ailleurs).


--
Noémie Lehuby

Le 27/10/2018 à 19:28, Paul Desgranges a écrit :
Normalement tu ne devrais plus trouver de "amenity=swimming_pool ayant 
un tag leisure/name/building", puisque justement c'était l'étape d'avant


Par contre j'ai cherché à l'instant les "amenity=swimming_pool" de 
type node seulement sur overpass-turbo https://overpass-turbo.eu/s/D9Q
et les premiers cas regardés ne peuvent pas être transformés 
directement en "leisure=swimming_pool"  !
- https://www.openstreetmap.org/node/1820461288 celui-ci c'est un 
"leisure=sports_centre + sport=swimming"
- https://www.openstreetmap.org/node/3648626536 celui-ci c'est un 
"leisure=sports_centre + sport=swimming"
- https://www.openstreetmap.org/node/1904181893 celui-ci c'est un 
bassin, mais il est déjà taggué comme bassin, et il est à coté d'un 
établissement qui n'est
pas taggué comme  "leisure=sports_centre + sport=swimming", et c'est 
plutôt ça qu'il faudrait faire du coup

-  et les autres que j'ai regardé aussi ...

Donc je crains que la conversion massive soit un peu risquée.

Il faudrait au moins couper en deux le traitement :
 - les nodes d'un coté (il y en a 102 
), par nature on ne peut pas 
connaître leur superficie :  j'ai l'impression qu'il faudrait regarder 
chacun des cas ? et dans n'y aurait-il pas un outil qui permettrait de 
se répartir la charge ?
 - les ways d'un autre coté (il y en a 6120 
), il faut les traiter en fonction de 
leur superficie
   -- les grandes superficies sont à regarder au cas par cas (par 
exemple https://www.openstreetmap.org/way/129407009

 est à transformer en "leisure=swimming_area")
   -- les petites superficies je ne sais pas en fait, regarder si on 
ne peut pas exploiter la présence d'un autre tag : 'phone=*' ou 
'access=customers' ou 'covered=yes' ?



Je pars une semaine, donc je ne pourrais pas participer à la suite de 
ceci la semaine prochaine en tout cas.

A bientôt
Paul



>Le 27/10/2018 /à 17:51:09 2018/, Marc marc a écrit :
> J'avais déjà passé en revue le critère des 2000m2 mais
> il peux toujours y avoir de nouveaux cas entre temps.
>De toute façon, je proposais de le faire avec ceinture
>et bretelles. et donc ces cas sont ignorés dans ma correction.
>Si personne n'a plus d'objection, je ferrai la conversion
> des amenity=swimming_pool n'ayant pas de tag leisure/name/building,
>ayant une surface < 2000m2 et situé en France
>en leisure=swimming_pool

Le 27/10/2018 à 15:55, Paul Desgranges a écrit :
Voilà ! J'ai fait ce dont on avait parlé (voir ci-dessous), donc il 
n'y a plus de "amenity=swimming_pool + name=*" ni de 
"amenity=swimming_pool + building=*" (sauf erreur ?)
(l'occasion à chaque fois de faire un peu de micromapping autour de 
ces établissements...)


Ce que je n'ai pas fait, c'est le traitement de tous les 
"amenity=swimming_pool" qui auraient une surperficie assez grande 
pour suspecter un "leisure=sports_centre",
cela reste une étape supplémentaire à faire avant le changement 
massif des autres "amenity=swimming_pool" ?


Bonne journée
Paul




je regarde de mon coté tous les cas qui sont exclus de l'édition de 
masse

Si je devais le faire

1- Je corrigerais d'abord les piscines avec un champ nom 'Piscine'
'Piscine privée' pour mettre ça dans la "description"
2- J'enlèverais du traitement massif tout ce qui peut l'être (comme
mentionné) :   les amenity=swimming_pool nommés (sauf les noms 
m. ci-dessus à traiter individuellement)   les 
amenity=swimming_pool qui sont aussi building

  les amenity=swimming_pool qui sont aussi leisure=sports_centre
 Car tous ceux là ont vocation à devenir des "leisure=sports_centre
sports=swimming name=... building=...", (sauf exception donc avec une

vérification visuelle)

3- Je regarderais à la mano les amenity=swimming_pool qui sont aussi
leisure=*
et puisque tu es partant pour le reste, que moi je considère bcp 
plus risqué, et bien ça se complète pas trop mal




___
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] Suivi de l'état du bâti par rapport au cadastre

2018-10-29 Par sujet marc marc 
Bonjour,

Le 29. 10. 18 à 18:19, Gautier Pelloux-Prayer a écrit :
> Un certain nombre d'outils de QA existent déjà sur OSM, alors pourquoi 
> ne pas en rajouter un nouveau ?!

hasard de calendrier, hier je me disais que je venais de trouver l'avant 
dernière pièce manquante pour faire "un peu mieux que "trop à la main"
https://github.com/sebastien-bugzilla/BatiOsm
http://forum.openstreetmap.fr/viewtopic.php?f=5=1762
l'autre pièce manquante c'était la tienne :)

> https://cadastre.damsy.net/ est une carte de suivi du bâti, commune par 
> commune, afin de connaître de quand date le dernier import du cadastre 
> réalisé. Cela permet de détecter :

double bravo !
- d'avoir eu l'idée et de l'avoir fait
- d'avoir éviter de recoder tous les briques au profit d'une utilisation 
de l'existant (cela permet qu'une amélioration des ces briques profite 
aussi à ton interface)

> - les villes qui n'ont jamais été importées (0 bâtiments + cadastre 
> vectoriel disponible)

j'ai pas trop compris comment on obtenait cette liste.
il y a l'air d'avoir 0.3% de commune concernée.
mais soit elles sont trop petite pour les trouver avec le zoom affichant 
la France entière, soit j'ai raté qlq chose :)

> - les communes qui n'ont /a priori/ jamais été importés, mais où du bâti 
> existe. Souvent, on trouve dans ces communes quelques bâtiments dessinés 
> à la main (IGN, Bing)… mais il manque 90+% du bâti.

l'outil BatiOsm (ou une comparaison sommaire entre le nombre de bâtiment 
osm et celui dans l'extract cadastre osm.fr) permettrait de se faire une 
idée des communes où le manque est le plus criant.
On peux aussi encore plus sommairement se baser sur la présence ou non 
de l'extract sur le serveur.

> - et sinon la date d'import des autres villes (en se basant sur le tag 
> /source/ des bâtiments).

cette méthode histoire étant de + en + dépréciée,
une futur amélioration pourrait tenir compte de la date de modif ou 
d'analyser l'historique (même si c'est bcp plus long)

> les fichiers Etalab

l'an passé il était urgent d'attendre.
quel est la situation actuelle ? quelqu'un les utilise ?
sur le wiki, si c'est documenté, c'est "sous le radar"
dans les pages concernant le cadastre

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

Re: [OSM-talk-fr] Borne de puisage

2018-10-29 Par sujet Gwenaël Jouvin 
Bonsoir,

Merci pour ce tuyau (d’arrosage) !

J’ai récemment ajouté un « poteau incendie » dont je me demandais pourquoi il 
était vert et si peu visible dans l’ombre… ce serait donc une borne de puisage 
? Pourtant, c’est physiquement un poteau utilisé ailleurs pour les points d’eau 
incendie de la région.
J’avais aussi ajouté color=green :-)

Pour les véritables poteaux incendie, attention j’en ai déjà vu avec un 
demi-capot jaune et l’autre rouge, impossible de savoir si c’est de la haute 
pression dedans.
Il y a également ce document qui permet d’apprendre un peu : 
http://www.sdis17.fr/sites/sdis17/files/fichiers/rddeci.pdf

Pour les points d’aspiration, ceci conviendrait-il ?
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dsuction_point


Gwenaël


Le 29/10/2018 à 11:55, Nicolas Moyroud a écrit :
> Merci Vincent (l'autre !) pour ces précisions.
> 
>> Tu en as de ces TOCs toi ;) 
> Oui tout plein, mais j'ai même pas envie de me faire soigner !
>> Certaines communes ne respectent pas ce code couleur. Je pense par exemple à 
>> Senlis (60) où une bonne proportion des "vrais" poteaux incendie sont du 
>> même vert que les bornes de puisage, juste pour une raison esthétique : 
> MDR. Pour des raisons esthétiques c'est un peu comme tagguer pour le rendu ça 
> ! D'après mon contact la réglementation devrait bientôt obliger à respecter 
> les codes par catégories d'hydrant. A voir...
>> pour les jaunes (je n'en ai jamais vues sauf à... Disneyland Paris :) ) je 
>> suppose qu'une valeur numérique pour ce même tag doit aller. Voir 
>> https://taginfo.openstreetmap.org/keys/fire_hydrant%3Apressure.
> 
> Pour les jaunes pas forcément évident de connaître la pression si ce n'est 
> pas indiqué dessus (mais peut-être que ça l'est systématiquement?). Y'a moyen 
> d'indiquer "supérieur à" pour une valeur numérique ? J'ai jamais fait ça...
> 
> On dirait que Disneyland aime mettre la pression. :-P
> 
> 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

[OSM-talk-fr] hebdoOSM Nº 431 2018-10-16-2018-10-22

2018-10-29 Par sujet theweekly . osm 
Bonjour,

Le résumé hebdomadaire n° 431 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/10846/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Suivi de l'état du bâti par rapport au cadastre

2018-10-29 Par sujet Gautier Pelloux-Prayer 

Bonjour,

Un certain nombre d'outils de QA existent déjà sur OSM, alors pourquoi 
ne pas en rajouter un nouveau ?!


https://cadastre.damsy.net/ est une carte de suivi du bâti, commune par 
commune, afin de connaître de quand date le dernier import du cadastre 
réalisé. Cela permet de détecter :


- les villes qui n'ont jamais été importées (0 bâtiments + cadastre 
vectoriel disponible)


- les communes qui n'ont /a priori/ jamais été importés, mais où du bâti 
existe. Souvent, on trouve dans ces communes quelques bâtiments dessinés 
à la main (IGN, Bing)… mais il manque 90+% du bâti.


- et sinon la date d'import des autres villes (en se basant sur le tag 
/source/ des bâtiments).


Par ailleurs, le site permet d'ouvrir dans un JOSM préconfiguré le bâti 
d'une commune (généré via https://cadastre.openstreetmap.fr, en 
attendant que les fichiers Etalab soit prêts ?), afin de le mettre à 
jour (via le plugin Conflation, ou la méthode de votre choix..).


En espérant que ça puisse servir à d'autres, je m'en sers 
personnellement pour dégommer du rose et du gris ;-). Retours bienvenus, 
ici ou sur https://gitlab.com/bagage/cadastre-conflation/issues


Bonne journée,

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

Re: [OSM-talk-fr] opening_hours contre les parcs parisiens

2018-10-29 Par sujet Francois Gouget 
On Fri, 26 Oct 2018, Philippe Verdy wrote:

> Le jeu. 25 oct. 2018 à 16:45, Francois Gouget  a écrit :
[...]
> Pas tout à fait :
> * le point-virgule dans un attribut indique une liste non-ordonnée (dont
> les éléments peuvent être librement permutés sans changement
> d'interprétation) : c'est valable normalement pour tout attribut OSM.
[...]
> Ce qui n'est pas le cas dans l'exemple ici car le premier élément de la
> liste séparée par point-virgule "08:00-17:45" couvre une bonne partie du
> second (qui indique des horaires différents pour certaines dates).
> 
> Il ne devrait donc pas y avoir de point-virgule du tout dans ton exemple,

Clairement opening_hours ne suit pas la règle. Mais mieux vaut suivre un 
standard, même pas très uniforme, plutôt que faire autre chose qu'aucune 
application ne saura décoder.

On peut aussi changer la règle mais je ne me lancerai pas là-dedans.


Ce qui est plus intéressant c'est que l'outil d'évaluation semble avoir 
un bug lié au passage à l'heure d'hiver.

  http://openingh.openstreetmap.de/evaluation_tool/

Par exemple pour "10:00-20:00" il affiche bien "open 10:00 to 20:00" 
pour le 2018-10-28 mais sur la même ligne le graphe retarde d'une heure 
et indique 11h à 21h !

On retrouve le même problème pour le passage à l'heure d'été le 
2018-03-25 mais cette fois-ci le graphe a une heure d'avance.

-- 
Francois Gouget   http://fgouget.free.fr/
  All generalizations are false, including this one.
 -- Mark Twain___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] micro-mapping de parkings

2018-10-29 Par sujet deuzeffe 


On 11/09/2018 21:20, marc marc wrote:

par contre les parking_space sont bien utile, par exemple si on veux 
affiner pour les places PMR ou simplement comme micromapping

Bonjour,

Il semble que les parking_space ne puissent pas être isolés mais 
obligatoirement être "inclus" dans un polygone parking (/Emplacement 
particulier au sein d'un parking/, je cite le wiki).


Sauf que ça me pose un problème lorsque il y a un "parking" constitué 
uniquement de 2-3 places PMR ou pour marquer les places PMR dans un 
parking_lane. Du coup, je crée des parking_space isolés (c'est mal).


Si vous avez des conseils pour mieux faire ce que je fais mal, je suis 
preneuse !


--
deuzeffe


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

Re: [OSM-talk-fr] Borne de puisage

2018-10-29 Par sujet Nicolas Moyroud 

Merci Vincent (l'autre !) pour ces précisions.

Tu en as de ces TOCs toi ;) 

Oui tout plein, mais j'ai même pas envie de me faire soigner !
Certaines communes ne respectent pas ce code couleur. Je pense par 
exemple à Senlis (60) où une bonne proportion des "vrais" poteaux 
incendie sont du même vert que les bornes de puisage, juste pour une 
raison esthétique : 
MDR. Pour des raisons esthétiques c'est un peu comme tagguer pour le 
rendu ça ! D'après mon contact la réglementation devrait bientôt obliger 
à respecter les codes par catégories d'hydrant. A voir...
pour les jaunes (je n'en ai jamais vues sauf à... Disneyland Paris :) 
) je suppose qu'une valeur numérique pour ce même tag doit aller. Voir 
https://taginfo.openstreetmap.org/keys/fire_hydrant%3Apressure.


Pour les jaunes pas forcément évident de connaître la pression si ce 
n'est pas indiqué dessus (mais peut-être que ça l'est 
systématiquement?). Y'a moyen d'indiquer "supérieur à" pour une valeur 
numérique ? J'ai jamais fait ça...


On dirait que Disneyland aime mettre la pression. :-P

Nicolas


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

Re: [OSM-talk-fr] Borne de puisage

2018-10-29 Par sujet Vincent de Château-Thierry 
Bonjour,

> De: "Nicolas Moyroud" 
> 
> La borne incendie étant un de mes TOCs ;-) 

Tu en as de ces TOCs toi ;)

> Je trouve plutôt bien ta proposition de tagging
> Vincent.
> Je pense que je vais rechercher mes bornes avec overpass pour mettre
> les tags que tu as proposé. D'autres avis ?

Je suis du même avis, ça colle avec ce que je fais par ailleurs comme par 
exemple ici :
https://www.openstreetmap.org/node/3374361144/history
J'ajoute une note car certains prennent ce schema de tags comme une description 
erronée d'une vraie borne incendie.

> Petite précision il existe aussi des bornes jaunes et bleues (je suis
> tombé sur ma première bleue récemment, encore jamais sur une jaune).
> J'ai posé la question à un géomaticien d'une collectivité que je
> connais
> et voici sa réponse :
> 
> - Les bornes de couleur "verte" sont des bornes de puisage (ce ne
> sont pas des poteaux incendie) équipé le plus souvent d'un compteur et qui
> serve à remplir les cuves des camions de lavage de rue, des cuves de
> traitement, etc.

Certaines communes ne respectent pas ce code couleur. Je pense par exemple à 
Senlis (60) où une bonne proportion des "vrais" poteaux incendie sont du même 
vert que les bornes de puisage, juste pour une raison esthétique :
https://www.google.fr/maps/@49.2046978,2.5869506,3a,42.4y,100.99h,82.01t/data=!3m7!1e1!3m5!1s20eyz88Sb-xhYClMxxFHBA!2e0!5s20170901T00!7i13312!8i6656

> Du coup à part la couleur, comment tagguer la pression supérieure à 8
> bars pour les jaunes et le fait que la borne est une borne d'aspiration
> pour les bleues ?

Pour les bleues, tu rajoutes :
fire_hydrant:pressure=suction cf. 
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dfire_hydrant#How_to_map et 
pour les jaunes (je n'en ai jamais vues sauf à... Disneyland Paris :) ) je 
suppose qu'une valeur numérique pour ce même tag doit aller. Voir 
https://taginfo.openstreetmap.org/keys/fire_hydrant%3Apressure.

vincent

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

Re: [OSM-talk-fr] Borne de puisage

2018-10-29 Par sujet Nicolas Moyroud 

Bonjour à tous,

La borne incendie étant un de mes TOCs ;-)  j'ai quelquefois ajouté dans 
OSM des bornes vertes. Mais jusqu'à récemment je ne savais pas de quoi 
il s'agissait donc je les avais toutes tagguées en 
emergency=fire_hydrant... mais j'ai toujours eu la bonne idée de mettre 
colour=green ! Je trouve plutôt bien ta proposition de tagging Vincent. 
Je pense que je vais rechercher mes bornes avec overpass pour mettre les 
tags que tu as proposé. D'autres avis ?


Petite précision il existe aussi des bornes jaunes et bleues (je suis 
tombé sur ma première bleue récemment, encore jamais sur une jaune). 
J'ai posé la question à un géomaticien d'une collectivité que je connais 
et voici sa réponse :


- Les bornes de couleur "verte" sont des bornes de puisage (ce ne sont 
pas des poteaux incendie) équipé le plus souvent d'un compteur et qui 
serve à remplir les cuves des camions de lavage de rue, des cuves de 
traitement, etc.
- Les bornes de couleur "rouge" sont des poteaux incendie raccordé à un 
réseau sous pression (eau potable ou eau brute);
- Les bornes de couleur "jaune" sont des poteaux incendie raccordé à un 
réseau sous pression dit "surpressé" (eau potable ou eau brute) avec une 
pression supérieure à 8 bars;
- Les bornes de couleur "bleue" sont des poteaux incendie d'aspiration 
(dans une cuve, dans une rivière, etc.)


Du coup à part la couleur, comment tagguer la pression supérieure à 8 
bars pour les jaunes et le fait que la borne est une borne d'aspiration 
pour les bleues ?


Nicolas


Le 24/10/2018 à 21:34, Vincent Bergeot a écrit :
on trouve quelques (37) amenity=hydrant 
https://taginfo.openstreetmap.org/tags/amenity=hydrant#overview


et dans ce cas on ajoute hydrant:type=pillar

fee=yes/no

color=green :)

ref=

Avis ?



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