<div dir="ltr">Pus lisible deu modèles dans des relations séparées ? Pas du tout ! Et cela complique tout en fait en ne sachant plus quelle relation utiliser, on va dénormaliser ennore plus les attributs.<div><br></div><div>

Regarde effectivement l'Espagne ou la Belgique et prétend que ce n'est pas lisible ! Et pourtant cela demande peu de membres dans les relations, qu sont classés à part avec des rôles clairement séparés qui ne gênent en rien la lisibilité des lites de chemins membres (qui elles sont carrément bordéliques, et le mot est faible, et totalement illisibles sans outils pour vérifier qu'on n'a pas pris par erreur un morceau de commune voisine ni oublié une petite enclave ou une ile exclavée qui fait échouer toute requête purement géométrique...).</div>

<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">Le 19 septembre 2013 15:34, V de Chateau-Thierry <span dir="ltr"><<a href="mailto:vdct@laposte.net" target="_blank">vdct@laposte.net</a>></span> a écrit :<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> De : "Christian Quest"<br>
<div class="im">><br>
Bien sûr, si l'on ne définissait les limites administratives que par un modèle<br>
surfacique, il faudrait revoir le fonctionnement d'osm2pgsql et de sûrement pas mal<br>
d'autres outils, mais je ne pense pas que quelqu'un propose un changement aussi radical.<br>
<br>
><br>
Le double modèle par contre peut avoir du sens. Il est en effet relativement difficile<br>
aujourd'hui d'utiliser les données OSM avec une vue hiérarchique sans créer ces<br>
géométries.<br>
<br>
><br>
Je viens d'extraire par exemple des listes de lieux (communes) sur différents pays avec<br>
la hiérarchie des découpages administratifs* et j'ai dû m'appuyer sur une base osm2pgsql<br>
pour sortir ça car il n'y a pas d'autre moyen pour le faire à par le is_in très mal<br>
renseigné et d'un format très aléatoire car textuel et non véritable structuré.<br>
<br>
><br>
J'aime aussi cet ajout de redondance qui permet de détecter les incohérences.<br>
<br>
><br>
A mon avis, au fur et à mesure qu'on a des zones complètes on devrait pouvoir ajouter les<br>
subarea en rôle supplémentaires dans les relations de découpages administratifs. Les<br>
outils ne sachant pas les exploiter les ignoreront tout simple comme il le font jusqu'à<br>
maintenant. L'Espagne fonctionne comme ça et à ma connaissance ça ne pose aucun problème.<br>
<br>
</div>Oui il y a déjà largement de quoi tester ce modèle. Mais je continue de plaider<br>
(comme 2 ans en arrière...[1]) pour l'utilisation de relations séparées. C'est plus<br>
lisible, et surtout, le type de ces relations ne peut pas être "boundary",<br>
ça mérite un type en propre, qui désigne ce que c'est sans ambiguïté : nested_areas ou<br>
quoi que ce soit qui évoque la récursivité et la notion de surface. Mais pas<br>
type=boundary : on ne parle pas de limites, ici. A creuser...<br>
<br>
vincent<br>
<br>
[1] : <a href="https://lists.openstreetmap.org/pipermail/talk-fr/2012-January/039636.html" target="_blank">https://lists.openstreetmap.org/pipermail/talk-fr/2012-January/039636.html</a><br>
<div class="im HOEnZb"><br>
Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?<br>
Je crée ma boîte mail <a href="http://www.laposte.net" target="_blank">www.laposte.net</a><br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org">Talk-fr@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-fr" target="_blank">https://lists.openstreetmap.org/listinfo/talk-fr</a><br>
</div></div></blockquote></div><br></div>