[OSM-talk-fr] Tagging Infrastructures de Santé

[Violaine Doutreleau]

Bonjour à tous et merci Marc pour ces éclaircissements !

Je retiens staff:chirurgien=yes/nombre, effectivement on était passé à 
côté de ça ! Pour le comptage des lits capacity:bed est pas mal pour le 
moment.. Dans la même idée que ce que tu disais, on pourrait étendre 
bed:<nom du service>=yes/nombre

Pour l'état d'une infra, on partirait sur disused:amenity=yes/type of 
amenity et abandonned:amenity=yes/type of amenity pour le moment du 
coup. Je vois au HOT Summit si ya d'autre niveaux d'états d'infra 
nécessaires à tagger.

Pour l'inventaire, j'ai tout de même des questions, car effectivement on 
a trouvé des usages de staff_count mais pas de wiki qui assure que la 
clé est approuvée. De même est-ce que tous les éléments adressés sur 
:/http://wiki.openstreetmap.org/wiki/Key:*/ sont sensés être sur 
/http://wiki.openstreetmap.org/wiki/Map_Features////
/

Également, des fois une page key=* n'a pas de status indiqué (exemple 
page Status : http://wiki.openstreetmap.org/wiki/Key:status). On ne sait 
pas si on peut utiliser le tag ou pas...

A+

Le 08/09/2017 à 18:48, marc marc a écrit :
> Le 08. 09. 17 à 17:50, Violaine Doutreleau a écrit :
>>    * j'ai vu passer un échange autour du tag capacity disant qu'il
>>      représentait une quantité quand un autre tag pouvait représenter un
>>      volume. Mais je trouve qu'il manque un tag 'nombre' type 'n' . J'ai
>>      vu des fois le tag capacity être utilisé comme capacity:bed, ce qui
>>      fait sens également. Mais ça marche dans ce cas car le nombre de lit
>>      fait aussi référence à la capacité du centre de santé. Par contre,
>>      il est aussi intéressant de connaitre le nombre de personnel de
>>      santé, voire même par spécialité, alors on sort du cadre capacity.
>>      Du coup la seule proposition trouvée ici c'est de mettre un
>>      bed_count, staff_count, puisqu'il semble que ce soit l'usage
>>      (rajouter _count à la fin de l'élément à compter). Par contre je
>>      trouve pas ça super logique, je suis plus pour un tag universel pour
>>      les nombres... Ou je rate quelque chose?
> Le but de François et moi était de rassembler autour d'un tag une
> proposition (l'amélioration des tag pour les bornes incendies) qui
> allait provoquer des nouveaux tags pour un utilisation finalement
> assez semblable à savoir la capacité maximale d'une infrastructure.
> Pour la petite histoire, le tag capacity ne serrait finalement
> probablement pas retenu, le pompier à l’œuvre estimant que le débit
> d'une borne n'est pas sa capacité (maximale) mais nominal.
> En ce sens, un hôtel de 4 lits, un parking de 10 places décrivent
> toutes la capacité que peux "supporter" l'objet de par sa conception.
> capacity:bed ou quelques chose du genre ferrait pour moi référence à la
> capacité maximale d'un hôpital par exemple, ceci pouvait être différent
> de la capacité "opérationnelle" variable par exemple selon le personnel.
> J'ignore cependant laquelle des 2 vous voulez encoder dans osm.
> La capacité théorique est assez stable. l'opérationnelle me semble délicate.
> Pour le personnel de santé, peut-être qu'une clef genre staff pourrait
> faire l'affaire. il faudrait peut-être aussi faire des recherches
> sur le wiki et/ou taginfo pour voir si ce genre d'info n'existe pas déjà
> Mais là aussi, est-ce que cela ne risque-t-il pas d'etre une donnée
> volatile ?
>
> il n'est pas obligatoire de tout suffixer par _count, de nombreux tag
> ont un wiki qui décrit par exemple une valeur yes pour dire que c'est
> présent (par exemple staff:chirurgien (à traduire évidement)
> ou un nombre pour rafiner l'information (par exemple 3)
> L'important étant surtout d'avoir un nom de clef non ambigu,
> uniforme et bien documenté.
> Il est aussi possible d'avoir des :count, l'avantage étant
> de permettre aux éditeur de reconnaître le type de clef
> Cela n'a cependant selon moi de sens que si la même clef a autre
> chose qu'un ":count"
>
>>    * comment pourrait-on définir l'état d'une infrastructure, si
>>      fonctionnel/opérationnel ou pas ? J'ai également vu pas mal de
>>      propositions mais je n'en ai pas trouvée une approuvée...
> L'inventaire est fait...  cfr mon email "les dates
> de terrain, de test fonctionnel, d'import, de source"
> N'hésite pas d'y répondre, je compte justement essayer de faire
> avancer cette "harmonisation". Je laisse encore quelques jours
> si un francophone à des remarques avant de tenter une harmonisation
> locale et/ou un avis sur la ml mondiale.
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

-- 
*Violaine Doutreleau*
Coordinatrice Missing Maps
CartONG <http://www.cartong.org>
mobile : 06.95.02.42.44
skype : doutreleau.violaine


_P Help save paper - do you need to print this email?_
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20170911/60f427e7/attachment.htm>