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...
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) 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". Fionn Le 19 septembre 2013 16:52, Philippe Verdy <verd...@wanadoo.fr> a écrit : > 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). > > 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. > > 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 ! > > 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. > > 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).. > > > > Le 19 septembre 2013 16:29, Pieren <pier...@gmail.com> a écrit : > > 2013/9/19 Pieren <pier...@gmail.com>: >> >> Et si on va dans la consolidation, on peut aussi rétablir tous les >> "is_in" qui ont été injustement supprimés. Et mettre des >> "addr:country=France" sur toutes les adresses en France. Parce qu'il y >> aura toujours quelqu'un qui trouvera ça plus pratique pour lui. Et >> pis, ça consolide et on pourra mieux détecter les incohérences. >> >> Pieren >> >> _______________________________________________ >> Talk-fr mailing list >> Talk-fr@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-fr >> > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
