On Sun, 6 Aug 2017, marc marc wrote:
[...]
> FG> Ce type de valeur n'est pas accepté par Osmose : width doit être une
> FG> valeur numérique sinon les logiciels ne sauront pas quoi en faire.
> la page wiki de width précise pourtant exemple à l’appui que c'est
> alphanumérique puisque pouvant contenir des unités.
Ok. Numérique hors unité.
> osmose a-t-il aussi des règles pour est_width ?
Non. Apparemment il ne vérifie que width et maxwidth:
https://github.com/osm-fr/osmose-backend/blob/master/plugins/Number.py
Cela dit d'après le wiki les règles sont les mêmes pour est_width :
Key:width (Redirected from Key:est width)
> il te semble préférable de diviser l'info entre 2 clefs ?
Je me contente de répéter ce qu'il y a dans le wiki et il dit que si la
valeur est estimée il faut la mettre dans est_width.
Après cela ne permet effectivement pas de noter les nuances comme
"plutôt moins d'un mètre" ou "plutôt plus d'un mètre". Si un consensus
émerge pour dire que ce type de nuance est important alors je suppose
qu'une solution se mettra en place mais je n'ai pas d'avis sur la
question.
Comme dit précédemment, pour ce qui est de l'accessibilité voir la clef
wheelchair qui permettra de prendre en compte d'autres critères :
marches, encombrement des pièces, toilettes accessibles, etc.
https://wiki.openstreetmap.org/wiki/FR:Key:wheelchair
> ou définir une règle précise susceptible d'être prise en compte par
> osmose et autres app ?
est_width a l'avantage de déjà exister et est donc potentiellement déjà
supporté par les applications existantes alors qu'une modification du
format du contenu de la clef width nécessitera de changer les
applications pour en tirer parti.
--
Francois Gouget <[email protected]> http://fgouget.free.fr/
A man can fail many times, but he isn't a failure
until he begins to blame somebody else.
-- John Burroughs_______________________________________________
Talk-fr mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-fr
