plutôt que de parler de notion "relationiste", moi je préfère parler de notion "ensembliste". - Certains sont trompés sur une fausse distinction entre modèle par frontières et modèle par surface alors que c'est exactement la même chose et fait avec les mêmes données de géométrie : des noeuds avec des coordonnées, et des chemins pour les assembler et un attribut ou un type unique permettant de donner une interprétation soit comme surface bidimentionnelle soit comme tracé filaire unidimentionnel. - Le nom du rôle "subarea" est trompeur. En fait ce serait plus clair si c'était "include" (notion ensembliste, totalement détaché de la géométrie) et on devrait pouvoir aussi ajouter un rôle "exclude" (notion également ensembliste) ce qui permet aussi de créer des exceptions locales à un modèle purement hiérarchique (les exceptions existent partout en géographie humaine, à commencer par nos administrations compliquées), mais cela ne change rien à la volumétrie et la modélisation. LE but n'est pas réellement de déinir des surfaces (au sens géométrique) mais bien des ensembles d'entités (il n'y a pas obligation non plus que les entités membres listées en "include" ou "exclude" soient disjointes entre elles, rien que le rôle "exclude" n'est utile que si justement il y a des intersections d'ensembles.
Si on doit modéliser ça: il vaut mieux en terme de volumétrie des données lister les communes comme membres dans la relation EPCI (avec un rôle "subarea" tel qu'il existe déjà, ou renommé "include"). plutôt que le contraire (équivalent topologique aux actuels tags "is_in" qui sont clairemetn indésirables). Donc Bordeaux sera listé comme membre de la relation de la CUB, plutot que le contraire (Bordeaux contient un membre avec un rôle spécifique pour donner son EPCI à fiscalité propre, la CUB, mais combien de membres (et de dôles spécifiques) faudra-t-il pour lister les EPCI et autres structures (administratives, ministérielles et régaliennes, commerciales, encironnementales....) auxquelles Bordeaux est attaché). Logiquement c'est Bordeaux qui est membre de la CUB et pas le contraire, soyons logique ! Un unique nom de rôle "include" suffit pour modéliser les ensembles (si on ajoute "exclude" c'est pour permettre d'inclure une sous-région comme les autres, mais d'en exclure un fragment, ce qui simplifie les choses. Le 19 septembre 2013 17:17, Fionn Halleman < fionn.halle...@valeurs-mobiles.fr> a écrit : > 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
