<div dir="ltr">A ce sujet le pire tag d'OSM (qui offre le plus d'ambiguïtés) est le tag "type=*" qui a été beaucoup trop "hacké" (selon ton expression) au point de devenir inutilisable avec des tonnes d'ambiguïtés un peu partout. Alors qu'il aurait fallu le spécialiser en "multipolygon:type=*", "castle:type=*", etc... selon les classes et sous-classes d'objets à définir.</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">Le 14 mai 2013 01:02, Philippe Verdy <span dir="ltr"><<a href="mailto:verdy_p@wanadoo.fr" target="_blank">verdy_p@wanadoo.fr</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">Le 14 mai 2013 00:54, Vincent Pottier <span dir="ltr"><<a href="mailto:vpottier@gmail.com" target="_blank">vpottier@gmail.com</a>></span> a écrit :<br><div class="gmail_extra"><div class="gmail_quote">

<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Depuis qu'on a inventé les opérateurs booléens, ça me semble plus simple et plus malin de les utiliser sur des tags existants que de créer un nouveau tag et d'ajouter une colonne dans la table postgis à chaque fois qu'un nouveau sujet apparaît.<br>



Sly s'en est très bien sorti sur layers [1]. Je suppose qu'il doit connaître les opérateurs booléens.<br></blockquote><div><br></div></div><div>Aucun rapport, tu ne comprends rien (ou ne veux pas comprendre), et je m'explique :</div>


<div><br></div><div>Les opérateurs booléens ne résolvent pas les ambiguités existant quand une relation doit servir à combiner des choses différentes. Moi je parle classe (au sens objet). Et selon la définition d'une classe d'objets ce ne sont PAS les mêmes attributs car ce sont des classes différentes.</div>


<div><br></div><div>Mais OSM n'offre aucun moyen de séparer les classes puisqu'il mélange tout. La seule solution c'est bien de nommer les attributs distinctement pour chaque classe quand ils ont des rôles très différents (orthogonaux donc pouvant se croiser de façon incompatible selon les deux usages actuels de admin_level=*).</div>


<div><br></div><div>La situation est très différentes dans OpenGIS, où les "classes" sont totalement différenciées (chaque classe est un "feature" disposant de sa propre table, caque ligne de tale OpenGIS définit une instance qui n'a rien à voir avec une autre instance dans une autre table OpenGIS, même si géométriquement elle est totalement identique).</div>


<div><br></div></div></div></div>
</blockquote></div><br></div>