<div dir="ltr"><div>En attendant le grand soir relationniste, j'ai fait ma liste de communes de la CUB à la main. Ceci dit, j'ai besoin des autres communautés urbaines aussi, et des autres niveaux d'EPCI plus tard...</div>
<div><br></div><div>Donc la discussion m'intéresse au-delà de mon petit problème bordelais : y a-t-il un consensus sur le fait que je peux ajouter un lien entre les relations commune et les relations EPCI ? Est-ce quelqu'un a un brouillon de comment ça se traduit dans les logiciels courants (me connaissant, je serais fichu de faire de la CUB une partie de Bordeaux au lieu du contraire)</div>
<div><br></div><div>PS : venant d'un monde adepte de bases de données plates comme des crêpes, c'est un authentique trésor que cette notion de "relation".</div><div><br></div><div>Fionn <br></div><div><br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">Le 19 septembre 2013 16:52, 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">Plutôt que les "is_in:*=*" ou les "left/right:*=*" franchement on peut consolider beaucoup plus facilement et avec énormément moins de données avec le modèle ensembliste (ne vous fiez pas au nom donné "subarea" pour le rôle, ce n'est pas du tout une notion surfacique à proprement parler car cela ne s'appuie pas du tout et ne nécessite d'ailleurs pas du tout la moindre donnée géométrique, on n'a besoin d'aucun chemin ni aucun noeud et aucune coordonnée).<div>


<br></div><div>Essayez avec le modèle purement géométrique d'obtenir la liste des 22 régions métropolitaines ! il faut télécharger actuellement plus de 800 000 chemins et plusieurs dizaines de millions de noeuds (et ces nombres sont sans arrêt en hausse au fur et à mesure qu'on affine les données). Et des heures de téléchargement, des millions de requêtes envoyées au serveur (ou bien on peut télécharger un gros fichier dump de la base et passer plusieurs jours à monter une base locale: quel gachis de temps pour tout le monde !) et consommer une bande passante réseau de plusieurs gigaoctets.</div>


<div><br></div><div>Alors que 22 membres en tout et pour tout (membres ensembliste) dans la base suffisent et permet d'avoir cette liste en quelques millisecondes avec 1 seule et unique requête qui nécessite une bande passante de moins d'1 Ko, ce qui est accessible à n'importe quel utilisateur ayant une relation internet lente ou un matériel très limité en capacité de stockage et de calcul !</div>


<div><br></div><div>Cela n'exclue pas de stocker aussi dans les relations les contours externes mais c'est autre chose et ce n'est pas une nécessité non plus ; déjà on ne le fait plus pour la France entière car on aurait beaucoup trop de chemins membres, la frontière est déjà scindée en plusieurs parties stockées à part et on a beucoup de mal à synchroniser les différents niveaux hiérarchiques de façon cohérente: mais ce sont ces frontières qui ont une redondance énormes car on doit les reporter à tous les niveaux (et on passe son temps à chercher comment les réparer efficacement et rapidement sans erreur.</div>


<div><br></div><div>Alors oui je suis favorable à la suppression des tags "is_in" (les membres de rôle "subarea" sont énormément plus efficaces), et des tags "left/right" beaucoup trop redondants et limités à une seule langue arbitraire (les chemins frontières avec leurs rôles "inner/outer" suffisent, ces rôles pouvant même être gérés comme synonymes puisque qu'on peut le déduire de la géométrie, si elle est correcte et complète, la distinction entre "inner" et "outer" est une facilité qui évite de devoir le calculer par un traitement complexe nécessitant la connaissance intégrale du détail des géométrie, mais ces distinctions ne sont pas volumineuses et restent utiles pour détecter des incohérences et vérifier l'intention du tracé initial; ces rôles 'inner" et "outer" sont vérifiables automatiquement de façon asynchorne, et permettent aux outils tiers de fonctionner aussi sans avoir à charger le détail complet des géométries)..</div>


<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">Le 19 septembre 2013 16:29, Pieren <span dir="ltr"><<a href="mailto:pieren3@gmail.com" target="_blank">pieren3@gmail.com</a>></span> a écrit :<div>
<div class="h5"><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2013/9/19 Pieren <<a href="mailto:pieren3@gmail.com" target="_blank">pieren3@gmail.com</a>>:<br>
<br>
Et si on va dans la consolidation, on peut aussi rétablir tous les<br>
"is_in" qui ont été injustement supprimés. Et mettre des<br>
"addr:country=France" sur toutes les adresses en France. Parce qu'il y<br>
aura toujours quelqu'un qui trouvera ça plus pratique pour lui. Et<br>
pis, ça consolide et on pourra mieux détecter les incohérences.<br>
<div><div><br>
Pieren<br>
<br>
_______________________________________________<br>
Talk-fr mailing list<br>
<a href="mailto:Talk-fr@openstreetmap.org" target="_blank">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></div></div><br></div>
<br>_______________________________________________<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>
<br></blockquote></div><br></div>