<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 09/06/2013 13:08, Philippe Verdy a
écrit :<br>
</div>
<blockquote
cite="mid:CAGa7JC16WMSXFeoabcsynaDu+FaLenf3A7EY2PTu5mWzfuBhZA@mail.gmail.com"
type="cite">
<div dir="ltr">Le 8 juin 2013 16:05, Vincent de Château-Thierry <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:vdct@laposte.net" target="_blank">vdct@laposte.net</a>></span>
a écrit :<br>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Et en toute logique, il faudrait si on l'applique, le
propager aussi aux boundary=administrative, à la place
d'admin_level.<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
Tout à fait.<br>
<blockquote
cite="mid:CAGa7JC16WMSXFeoabcsynaDu+FaLenf3A7EY2PTu5mWzfuBhZA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div style="">Certainement pas (ou à la limite seulement
dans les relations administratives (et qui ne sont QUE
administratives et ne servent pas aussi de limites pour
autre chose).</div>
<div style="">L'ennui c'est pour les ways (fermés ou non)
qui ont des utilisations multiples. Il se posera alors la
question de savoir à quel autre tag présent sur ce way
correspond ce "level" car justement le "level" n'est PAS
orthogonal mais lié à un seul autre tag.<br>
</div>
<div style=""><br>
</div>
<div style="">C'est bien pour ça qu'on a un tag nommé
"admin_level" (lié très fortement à
boundary=administrative pour lui apporter une
sous-précision) et qu'on a relevé un problème
d'interprétation quant on l'a appliqué (à tord) sur les
frontières religieuses (qui n'ont rien de commun avec des
frontières administratives).</div>
</div>
</div>
</div>
</blockquote>
ON, je en l’occurrence, l'ai appliqué après réflexion.<br>
On, Sly en l’occurrence, avait repéré un problème sur layers.osm.fr
et a très bien réussi à le résoudre.<br>
ON, toi en l’occurrence, ne semble pas avoir perçu comment Sly avait
résolu le problème sur layers.osm.fr<br>
<blockquote
cite="mid:CAGa7JC16WMSXFeoabcsynaDu+FaLenf3A7EY2PTu5mWzfuBhZA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style=""><br>
</div>
<div style="">Franchement je ne comprend pas l'utilité même
de vouloir unifier des tags sous un même nom alors qu'ils
ont des significations complètement diférentes et ne sont
pas liés aux mêmes données (et clairement pas orthogonaux
comme peuvent l'être "name", "url", "wikipedia",
"natural", "landuse" et "boundary").</div>
</div>
</div>
</div>
</blockquote>
Franchement je ne comprends pas l'utilité de multiplier les clefs
alors qu'une bonne logique booléenne résout les problèmes.<br>
Réemployer les mêmes clefs, ça permet de minimiser les clefs ! Ça
permet d'alléger les tables dans postgres.<br>
Ça permet d’utiliser la logique plutôt que le bavardage.<br>
<blockquote
cite="mid:CAGa7JC16WMSXFeoabcsynaDu+FaLenf3A7EY2PTu5mWzfuBhZA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style="">Il faudrait réfléchir plus sérieusement.</div>
</div>
</div>
</div>
</blockquote>
Tout à fait. Tu peux t'y mettre.<br>
<br>
Heureusement que d'autres ont déjà commencé ! Ce qui permet
d'utiliser des mêmes clefs secondaires conjointement avec des clefs
primaires différentes : produce, operator... orthogonaux ou pas.<br>
--<br>
FrViPofm<br>
</body>
</html>